Bug#840424: Could you fix the error that is found by verilog-mode testing on Debian?

[Kiwamu Okabe]

Hi Wilson,

On Sat, Oct 15, 2016 at 3:48 PM, Kiwamu Okabe  wrote:
> I found that! If we run "make test" on fakeroot environment, we get such 
> error!

I would like to fix this problem on Debian side by running "make test"
on normal user.

Best regards,
-- 
Kiwamu Okabe at METASEPI DESIGN

Bug#840672: RFS: libcork/0.15.0+ds-7~exp1 -- simple, easily embeddable, cross-platform C library

[Gianfranco Costamagna]

Hi,

>Actually it's an issue raised by James Clarke:
>- https://lists.debian.org/debian-sparc/2016/08/msg00035.html
>
>As he pointed out, it's a bug in cmake config in libcork source tree.
>
>It involves library transition, and I was not familiar with it, so I
>didn't try to fix it until recently I learned how to do transition so
>here's the upload and RFS report.
>
>Since all packages depends on libcork is maintained by me, and I can
>update those rdepends package accordingly, so there's no risk for this

>transition.

well, this isn't the real problem.
The real problem is that you have uploaded a version without the patch
https://lists.debian.org/debian-sparc/2016/08/msg00035.html
There is a patch here, you should apply it then.

G.

Bug#840424: RFS: verilog-mode/0:20160910.debfc6d.vpo-1

[Kiwamu Okabe]

Hi all,

How to install elisp files of verilog-mode by "dh_elpa" style? If you
build my repo now, you'll see following:

  $ pwd
  /home/kiwamu/deb/verilog-mode
  $ git log | head -1
  commit 0321d9aeb34ff6e20bcb586b820653d30c92b031
  $ cat debian/elpa
  e/*.el
  $ gbp buildpackage -us -uc --git-ignore-new --git-verbose
  --snip--
  === ALL TESTS PASSED
  make[2]: Leaving directory '/home/kiwamu/deb/verilog-mode'
  make[1]: Leaving directory '/home/kiwamu/deb/verilog-mode'
   fakeroot debian/rules binary
  dh binary --with elpa
 dh_testroot
 dh_prep
 dh_auto_install
  make -j1 install
DESTDIR=/home/kiwamu/deb/verilog-mode/debian/elpa-verilog-mode
AM_UPDATE_INFO_DIR=no
  make[1]: Entering directory '/home/kiwamu/deb/verilog-mode'
  perl makechangelog --git verilog-mode.el > ChangeLog
  cp mmencoded_verilog-mode
/home/mac/development/www.verilog.com/src/data/mmencoded_verilog-mode
  cp: cannot create regular file
'/home/mac/development/www.verilog.com/src/data/mmencoded_verilog-mode':
No such file or directory
  Makefile:128: recipe for target
'/home/mac/development/www.verilog.com/src/data/mmencoded_verilog-mode'
failed

The "dh_binary" tries to run "make install", but the make target is
for upstream author's release process and not for installing elisps
into destdir. I would like to override "dh_auto_install" and run some
process under "debian/elpa" settings. How to do that?

All of the build log is found at following:

  https://gist.github.com/master-q/2a68e10e03883425138f718c4fefe3e3

My Debian repo is following:

  http://anonscm.debian.org/cgit/pkg-emacsen/pkg/verilog-mode.git

Best regards,
-- 
Kiwamu Okabe

Bug#840811: npm2deb: Fails to handle utf-8 characters

[Shanavas M]

Package: npm2deb
Version: 0.2.5-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
npm2deb fails to handle unicode characters.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
npm2deb search invert-kv

   * What was the outcome of this action?
npm2deb crashed with error:
'ascii' codec can't decode byte 0xe2 in position 102: ordinal not in range(128)

The invert-kv package contains a non ASCII character in description which 
npm2deb fails to handle. 

   * What outcome did you expect instead?
npm2deb should not fail.

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

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

Versions of packages npm2deb depends on:
ii  devscripts2.16.8
ii  node-github-url-from-git  1.4.0-1
ii  npm   1.4.21+ds-2
ii  python3-dateutil  2.5.3-2
pn  python3:any   

npm2deb recommends no packages.

npm2deb suggests no packages.

-- no debconf information

Bug#840672: RFS: libcork/0.15.0+ds-7~exp1 -- simple, easily embeddable, cross-platform C library

[Roger Shimizu]

On Sat, Oct 15, 2016 at 4:11 PM, Gianfranco Costamagna
 wrote:
> Hi,
>
>>Actually it's an issue raised by James Clarke:
>>- https://lists.debian.org/debian-sparc/2016/08/msg00035.html
>>
>>As he pointed out, it's a bug in cmake config in libcork source tree.
>>
>>It involves library transition, and I was not familiar with it, so I
>>didn't try to fix it until recently I learned how to do transition so
>>here's the upload and RFS report.
>>
>>Since all packages depends on libcork is maintained by me, and I can
>>update those rdepends package accordingly, so there's no risk for this
>
>>transition.
>
> well, this isn't the real problem.
> The real problem is that you have uploaded a version without the patch
> https://lists.debian.org/debian-sparc/2016/08/msg00035.html
> There is a patch here, you should apply it then.

James provided a patch to fix "unaligned access" issue at above
thread, and he also pointed out the SONAME version issue, which he
didn't provide a patch, so I created the patch based on his
suggestion.

As the original issue of the "unaligned access" patch only occurs on
the sparc64 platform, I need some time to fully test whether the patch
applies well on other platform.
Considering transition freeze is drawing near (3 weeks later), so I
want to push the transition first, and after the transition finished I
can handle this unaligned access patch James provided.

Hope it make things clear to you.
Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339

[Paul Fertser]

Hey Paul,

Many thanks for your review, please see some answers below.

On Thu, Oct 13, 2016 at 11:55:29AM +0800, Paul Wise wrote:
> > Cc: Oleksij Rempel 
> 
> Please use the X-Debbugs-CC pseudo-header when submitting bugs instead

Noted. Nice feature.

> > I am looking for a sponsor for my package "open-ath9k-htc-firmware"
> 
> Correct me if I'm wrong but IIRC either yourself or Oleksij have
> commit/release access upstream?

Well, basically Oleksij co-maintains the upstream repository with
Adrian Chadd (former QCA employee).

I have commit rights for the packaging branch in Oleksij's personal
repo.

> The comments for the overrides for lintian tag source-is-missing
> should indicate which file is the source for each prebuilt file. I
> would have one comment per instance of the tag.

In this particular case it's unclear if the source is really missing
or not. If you say the upstream sources absolutely MUST be repackaged
if they include binaries that we can't get the sources for even if the
said binaries are removed automatically before building and are not
needed for the process anyhow, well, I'll try to investigate the
details and will come back with the answer.

> Just one comment saying they are removed at build time is enough for
> all of the overrides for lintian tag
> source-contains-prebuilt-binary.

OK.

> Personally, I would suggest removing all of these files from the
> upstream git repository and always building them from source. If you
> need to keep them, put them in tarballs in the github releases.

Not practical, please see below.

> Personally, I would recommend the generated files docs/*.png be
> removed from the upstream git repo and rendered at build time from
> their source SVG files if they are needed.

Noted. Probably not anything to worry about if we'll have to repack
upstream sources anyway due to proprietary objects, the *.png will be
removed along the way.

> I think you should also remove the prebuilt files before
> dh_auto_configure so that they can never get used by a build, even a
> manual one where `debian/rules clean` is not run.
...
> I would use a debian/clean file instead of override_dh_clean.

Noted.

> What is the reason for removing the docs/ and sboot/ directories in
> override_dh_clean? AFAICS both of these contain source files. IMO you
> should just remove the generated files.

Since neither are needed for building the actual firmware, it's easier
to remove them completely rather than mess with individual files.

The device hardware includes not only the microcontroller but also
some RAM and ROM. The tricky part here is that ROM is a mask ROM one,
that is, truly read-only. During the development a set of generic
useful functions was identified and QCA produced a batch of ICs with
those functions present in the mask ROM memory. The main firmware is
stored on a host device and is loaded dynamically to target's RAM. To
cut down on the amount of RAM needed, it makes use of those generic
functions stored in ROM. sboot/ directory contains (probably partial,
will have to investigate this further, if absolutely needed; probably
repacking the upstream tarball would be easier though) sources for the
said ROM as well as the binaries that are supposed to be identical to
the ROM's contents. During the build some header files and linker
scripts are used to provide external linkage to the generic functions,
the said headers and scripts are placed in the target_firmware/
directory, so sboot/ can be removed completely. For some debugging
purposes it might be beneficial to inspect the sources of the
mentioned functions and sometimes even the resulting binaries. So
sboot/ should probably stay in the upstream repository for the
reference purposes. Making upstream package it separately sounds like
additional hassle for no practical gain (except for the Debian
packaging purposes probably), it's way easier to have a single git
repository contain everything useful for development and debugging.

> The cmake part of the build process does not print compiler
> invocation. Debian requires full compiler flags/output in build logs.
> For cmake usually debhelper automatically passes
> -DCMAKE_VERBOSE_MAKEFILE=ON but it doesn't seem to be working here?

Will investigate.

> The debian/watch file needs adjusting for the new source package name:
> s/firmware-ath9k-htc/open-ath9k-htc-firmware/
> 
> Personally I would leave "debian uupdate" out of the watch file
> because it can be annoying for people who just want to download.

Indeed. I'm new to this, so just copied the example from the uscan
manpage.

> Please get the FSF address corrected in the upstream copyright info.

This one makes me wonder if it'd be the correct way to go. I assume
only the copyright holder can do this, and spending time contacting
eCos developers (and probably lawyers) just to get it right for some
really old code seems impractical. I'd consider this to be an upstream
issue unrelated to Debian packaging. Please correct me

Bug#840812: libthai FTCBFS: does not honour DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: libthai
Version: 0.1.25-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Thank you for applying my patches to libdatrie so quickly. Now the
libthai cross build gets further along and fails running tests. Like
libdatrie, tests need to be skippable for cross compilation. Please
consider applying this patch as well.

Helmut
diff --minimal -Nru libthai-0.1.25/debian/changelog 
libthai-0.1.25/debian/changelog
--- libthai-0.1.25/debian/changelog 2016-06-28 10:29:47.0 +0200
+++ libthai-0.1.25/debian/changelog 2016-10-15 09:39:32.0 +0200
@@ -1,3 +1,10 @@
+libthai (0.1.25-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Honour DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 15 Oct 2016 09:39:20 +0200
+
 libthai (0.1.25-1) unstable; urgency=medium
 
   * Imported Upstream version 0.1.25
diff --minimal -Nru libthai-0.1.25/debian/rules libthai-0.1.25/debian/rules
--- libthai-0.1.25/debian/rules 2016-06-28 10:29:47.0 +0200
+++ libthai-0.1.25/debian/rules 2016-10-15 09:39:18.0 +0200
@@ -20,9 +20,11 @@
 # No test for data, doc
 override_dh_auto_test-indep:
 
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
 override_dh_auto_test-arch:
$(MAKE) -C data
$(MAKE) -C tests check
+endif
 
 override_dh_auto_install-indep:
$(MAKE) -C data install DESTDIR=$(CURDIR)/debian/tmp

Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps

[Rogier Wolff]

On Sat, Oct 15, 2016 at 01:00:28AM -0400, Matthew Gabeler-Lee wrote:
> On Thu, 13 Oct 2016, Rogier Wolff wrote:
> 
> >No! Not a "more reasonable" value! An outrageous value!
> >
> >You have a network where 5 hops-in-a-row don't conform to IP standards. And
> >then you expect mtr to work?
> 
> traceroute works fine, ping works fine, tcp connections work fine
> ... but mtr is special and should fail just because the network
> doesn't meet your ideals?  And yeah, MTR would work fine in this
> case if it didn't decide to give up "just because".  The "give up
> after 5" is the /only/ thing preventing it from working properly.
> 
> To put a concrete example to it, consider the case of tunnels, esp.
> VPNs.  It is common for the TTL of the tunneled packet to be copied
> to the outer packet for various good reasons.  But this means that
> traceroute through that tunnel will not return the errors for any
> TTL value that causes the packet to be dropped at points between the
> endpoints of the tunnel, because the error will be returned back to
> the tunnel endpoint, not the original sender.
> 
> Happens with OpenVPN (it's even in their FAQ I think), happens with
> the Cisco IPSEC site-to-site tunnel used at my employer.

To discover the route to a "random" host we could just send out probes
for every distance up to the max TTL. This is wasteful because most of
the targets will be within say 12 hops, so sending out 64 packets is
too much. Another common situation is that you start using mstr to
determine where in the network packets are being dropped. If there is
a 100% blockage at some point, after that moment no further probe will
return results. So to prevent unnecessary load on the network (which
when you're running mtr is already experiencing difficulties) we put
an upper limit on the number of hosts that don't respond. 

Your example with a tunnel is a good one. At first I thought the TTL
should be set to "max" when entering the tunnel, but on second thought
that would be bad: routing / tunneling mishap could then "rejuvenate"
a packet each time it enters the tunnel leading to chaos (packets that
keep running circles and never die). 

Anyway, I've already increased the limit in the development version,
and I thank you for explaining to me why this is becoming more common.

Roger. 


-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Bug#840813: mark xorg-docs-core Multi-Arch: foreign

[Helmut Grohne]

Package: xorg-docs-core
Version: 1:1.7.1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:xterm

xterm cannot be cross built from source, because its build dependency on
xorg-docs-core is unsatisfiable. In general, Architecture: all packages
that are not marked Multi-Arch: foreign cannot satisfy cross
Build-Depends at all. I propose marking it Multi-Arch: foreign, because
it is Architecture: all, has no maintainer scripts or depdendencies. The
same holds for xorg-docs. Please consider applying the attached patch.

Helmut
diff -u xorg-docs-1.7.1/debian/changelog xorg-docs-1.7.1/debian/changelog
--- xorg-docs-1.7.1/debian/changelog
+++ xorg-docs-1.7.1/debian/changelog
@@ -1,3 +1,10 @@
+xorg-docs (1:1.7.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark all packages Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 15 Oct 2016 09:46:53 +0200
+
 xorg-docs (1:1.7.1-1) unstable; urgency=medium
 
   * Team upload.
diff -u xorg-docs-1.7.1/debian/control xorg-docs-1.7.1/debian/control
--- xorg-docs-1.7.1/debian/control
+++ xorg-docs-1.7.1/debian/control
@@ -24,6 +24,7 @@
 Depends: ${misc:Depends}
 Suggests: xorg-docs
 Replaces: xorg-docs ( << 1:1.4-5 )
+Multi-Arch: foreign
 Description: Core documentation for the X.org X Window System
  This package contains core documentation for the X.org X Window
  System. This currently includes only a set of manpages which are
@@ -34,6 +35,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Conflicts: xprt-xprintorg (<= 1:0.1.0.alpha1-10)
 Replaces: xspecs (<= 1:1.2+git20061105-2), xprt-xprintorg (<= 
1:0.1.0.alpha1-10)
+Multi-Arch: foreign
 Description: Miscellaneous documentation for the X.org X Window System
  This package contains various documents on the X.org X Window System
  including the release notes for the current version and instructions on

Bug#840814: ITP: python-bitbucket-api -- library to interact with bitbucket API

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: python-bitbucket-api
  Version : 0.5.0
  Upstream Author : Name 
* URL : https://github.com/Sheeprider/BitBucket-api
* License : ISC
  Programming Lang: Python
  Description : library to interact with bitbucket API

 python-bitbucket-api provides an API to use the following features in
 bitbucket:
  * Access public user informations
  * Access public or private repositories, tags or branches
  * Create, update or delete one of your repository
  * Access, create, update or delete a service (hook)
  * Access, create or delete an SSH key
  * Download a repository as an archive
  * Access, create, update or delete an issue
  * Access, create, update or delete an issue comment

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#822159: ocsinventory-server: New version available: 2.2

[Peter Gervai]

Package: ocsinventory-server
Version: New versions available, latest now 2.2.1
Followup-For: Bug #822159

2.2.1 available since 10th june, 2016.

(Current version depends on mysql-client instead of virtual-mysql-client thus 
blocking
mariadb installs. And it's quite old anyway.)

Is there anything actually blocking the packaging of the new release, or you
just didn't find the time? Can we help?

Merci!

Bug#838833: asterisk: AST-2016-006

[Petter Reinholdtsen]

The issue is tracked by the security team as
https://security-tracker.debian.org/tracker/CVE-2016-7550 >.

I guess the easiest fix is to upgrade the unstable version from upstream,
as the older versions of Debian are not affected and a quick search did not
point me to a patch.

-- 
Happy hacking
Petter Reinholdtsen

Bug#840815: acl2: FTBFS on some architectures: HARD ACL2 ERROR in ASSERT$: Assertion failed:

[Emilio Pozuelo Monfort]

Source: acl2
Version: 7.2dfsg-2
Severity: serious

Hi,

Your package failed to build on mips64el, as well as in some other
(non-release) architectures. From the mips64el log:

start address -T 0xc0c0f0 ;; Finished loading #p"boot-strap-pass-2.o"
;; Loading "defpkgs.lisp"
[GC for 95 SYMBOL pages..(T=9).GC finished]
[GC for 334 CONS pages..(T=10).GC finished]
[GC for 344 CONS pages..(T=10).GC finished]
[GC for 344 CONS pages..(T=10).GC finished]
[GC for 344 CONS pages..(T=10).GC finished]
;; Finished loading "defpkgs.lisp"
[GC for 74 SFUN pages..(T=10).GC finished]


HARD ACL2 ERROR in ASSERT$:  Assertion failed:
(ASSERT$ (AND (TRUE-LISTP DIR)
  (EQ (CAR DIR) :ROOT))
 (LET* ((MSWINDOWS-DRIVE (MSWINDOWS-DRIVE # STATE))
(TMP (IF MSWINDOWS-DRIVE # "/")))
   (DOLIST (X DIR)
   (WHEN (STRINGP X) (SETQ TMP #)))
   (WHEN (STRINGP NAME)
 (SETQ TMP (CONCATENATE # TMP NAME)))
   (WHEN (STRINGP TYPE)
 (SETQ TMP (CONCATENATE # TMP "." TYPE)))
   (LET ((NAMESTRING-TMP #)
 (NAMESTRING-TRUENAME #))
(COND (# TMP) (# TMP) (T # #)
(See :DOC set-iprint to be able to see elided values in this message.)



ACL2 Error in ACL2-INTERFACE:  Evaluation aborted.  To debug see :DOC
print-gv, see :DOC trace, and see :DOC wet.


Error: 
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by INITIALIZE-ACL2.

Raw Lisp Break.
SIMPLE-ERROR: ACL2 Halted

Broken at APPLY.  Type :H for Help.
1  Return to top level. 
ACL2>>make[2]: Entering directory '/«PKGBUILDDIR»'
ACL2_WD is /«PKGBUILDDIR»
Initialization FAILED: acl2-status.txt should contain :INITIALIZED.
GNUmakefile:340: recipe for target 'check_init_ok' failed
make[2]: *** [check_init_ok] Error 1


Full logs at https://buildd.debian.org/status/package.php?p=acl2

Emilio

Bug#840812: libthai FTCBFS: does not honour DEB_BUILD_OPTIONS=nocheck

[Theppitak Karoonboonyanan]

On Sat, Oct 15, 2016 at 2:43 PM, Helmut Grohne  wrote:
> Source: libthai
> Version: 0.1.25-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> Thank you for applying my patches to libdatrie so quickly. Now the
> libthai cross build gets further along and fails running tests. Like
> libdatrie, tests need to be skippable for cross compilation. Please
> consider applying this patch as well.

Yes, I was expecting this report while preparing the same change
to libthai. It will be uploaded soon.

Thanks for your check.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#840817: mpi4py FTBFS on alpha: libm.so.6 does not exist on Alpha (but libm.so.6.1 does)

[Michael Cree]

Source: mpi4py
Version: 2.0.0-2
Severity: important
Justification: fails to build from source (but built in the past)
User: debian-al...@lists.debian.org
Usertags: ftbfs

mpi4py FTBFS on Alpha with the following failure in the test suite [1]:

FAIL: testDL1 (test_dl.TestDL)
--
Traceback (most recent call last):
  File "/<>/test/test_dl.py", line 18, in testDL1
  self.assertTrue(handle != 0)
  AssertionError: False is not true


In tests/test_dl.py is:

def testDL1(self):
if sys.platform == 'darwin':
libm = 'libm.dylib'
else:
libm = 'libm.so.6'

And it proceeds to try to open libm which on Alpha fails because
the C library version is 6.1, not 6.  The code should really be
detecting the CPU and if it is Alpha should use 'libm.so.6.1' as
the math library.  (I presume it should also be checking for the
hurd and kfreebsd as they also have different C library versions,
but those builds don't get far enough to see this problem.)

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mpi4py&arch=alpha&ver=2.0.0-2&stamp=1473761717

Bug#840781: sddm: Missing option to choose window maker

[Maximiliano Curia]

¡Hola Helge!

El 2016-10-14 a las 21:17 +0200, Helge Kreutzmann escribió:
Package: sddm 
Version: 0.13.0-1 
Severity: important


Until the last update sddm (which I assume is the successor to kdm 
which I used on stable) was enabling users to choose the window 
manager of choice. Unfortunately, this was not automatic.


This is no longer the case, i.e. all users are "stuck" with the window 
manager last used before the update.


The session selector should be visible in the bottom left corner of the screen 
(at least using the breeze theme). Someone mentioned a similar issue but 
immediately mentioned that the issue went away when finishing the upgrade, 
unfortunately I don't remember the exact details.


I haven't been able to reproduce this.

In my use case my wife uses plasma, while I'm using window maker. Now 
we both use window maker.


Or is there another x session manager more suited for multi user (and 
multi preference users) systems?


Most other display managers manage this correctly, for example lightdm.

Alternatively, you could use a per user ~/.xsession file to workaround the 
having to select the session type every time, this should work with sddm 
(selecting the Xsession option) and even with xdm (which is the oldest dm 
around).


Happy hacking,
--
Porque no respeta el orden natural en el que se leen las cosas
> ¿Por qué contestar al principio del mensaje es malo?
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#840598: RFS: poppassd/1.8.7-1 [QA]

[Gianfranco Costamagna]

control: tags -1 moreinfo

(tagging moreinfo, to avoid accidental uploads, until the things are solved)


>An NMU for the RC bug was entirely appropriate.  Someone not responding

>to your other bugs immediately is not a particularly good reason for a
>hostile package takeover.


completely true :)

>I have bugs in the BTS that are years old without responses.  If I took
>over all those packages, I'd have even less free time than I do today,
>and it would also be somewhat insane.


this is true too, nobody will upload something without your prior consent of
course.
But since you are active, how do you feel about somebody sponsoring this one
with some changes?
e.g. we can convert in a Team Upload, add the previous NMU to changelog entry,
and fix the outstanding issues
(e.g. Peter did a lot of upstream nice work, that would be nice to see in 
Debian)
+* Version 1.8.7 - Peter Colberg optimized the build configuration to make 
distribution builds easier

also, the new release can be syncd in Ubuntu, since it contains the delta.

So, at the end it would be nice to do some refactoring for the package :)
Can this sound as a good plan?
thanks!

Gianfranco

Bug#840799: RFS: libcbitcoin-perl/0.2-1

[gregor herrmann]

On Sat, 15 Oct 2016 09:38:03 +0900, Joel DeJesus wrote:

> I am looking for a sponsor for my package "libcbitcoin-perl", a
> Perl wrapper for the other package I am trying to get a sponsor
> for, picocoin.

Since libcbitcoin-perl is already in a pkg-perl git repo, there's no
need for putting it on mentors and filing RFS bugs; someone from the
Debian Perl Group will review and upload it directly from its git
repo. But this can only happen once picocoin is available.

As a first feedback after just looking at debian/ for a few seconds:
It seems that you created the package with dh_make, and probably with
an old version. I suggest to remove (well, rename / move away
locally) the whole debian/ dir and user dh-make-perl (from unstable
or from git) with the --pkg-perl option. This should give you a
skeleton where we can work from.

I also suggest that you take a look at lintian which is an enormous
help to get a package into shape :)

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bob Dylan: Oxford Town


signature.asc
Description: Digital Signature

Bug#839987: Pending fixes for bugs in the libcompress-raw-lzma-perl package

[pkg-perl-maintainers]

tag 839987 + pending
thanks

Some bugs in the libcompress-raw-lzma-perl package are closed in
revision 898ccbda13fe5e910ae1a95f979e9afc92ad9784 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libcompress-raw-lzma-perl.git/commit/?id=898ccbd

Commit message:

Add patch to turn off check for liblzma version at runtime.

Closes: #839987

Bug#828601: [pkg-wpa-devel] Bug#828601: wpa: FTBFS with openssl 1.1.0

[Andrew Shadura]

Hi,

On 14 October 2016 at 23:36, Sebastian Andrzej Siewior
 wrote:
> On 2016-09-01 23:54:23 [+0200], Sebastian Andrzej Siewior wrote:
>> The latest build failed against 2.5-2+v2.4-2. I see that 2.5-3 is
>> prepared for experimental. Upstream's git seems to build against openssl
>> 1.1.0 (didn't test but the commits make it look like).
>
> 2.6 has been released almost two weeks ago and according to the
> changelog it builds against openssl 1.1.0

Cool, thanks, I'll have a look at it tomorrow.

-- 
Cheers,
  Andrew

Bug#780036: vagrant: Vagrant does not Windows guests via 'winrm' [workaround]

[Danny Edel]

On Sun, 08 Mar 2015 10:42:34 -0500 Peter Gallagher
 wrote:
> Attempting to install the winrm GEM manually does not change the behaviour. 
> The
> DEB package provided at https://www.vagrantup.com/download-archive/v1.6.5.html
> does not display this behaviour and works as expected.

Hello,

I came across the same problem today, but as a workaround you can call
(as the same user you normally use vagrant)

$ vagrant plugin install winrm winrm-fs

to install the winrm (and winrm-fs, which is needed next) gems into
vagrant's own gem store (located in ~/.vagrant.d/gems/).  This allows to
manage windows guests in the meantime, until ruby-winrm is packaged for
Debian.

Cheers,

Danny

Bug#791724: RFS: w1retap/1.4.4-1 [ITP] -- Data logger for 1-Wire weather sensors

[Gianfranco Costamagna]

Hi,

>The plugin packages contain .so files, the --noscripts option stops an

>ldconfig run when installing. Without it I get a lintian useless
>ldconfig run warnings.


well, I usually don't care about such warnings, but I wonder if somewhen
in the future the package starts shipping an external shared library
and ldconfig won't be run because of this.
(I'm not asking to change this, just wondering about a possible future
side effect, and please note I have no clues about the possibilities
of this scenario, and probably lintian will complain in such case)




No, it's a odbc plugin and the mysql plugin is separate. The confusion was
caused by a typo on my part. In anycase, both are now fixed.


>> patches: remove-data-time-macro.patch
>> you can dpkg-parsechangelog and export the changelog date an build date.
>> (this will make the package reproducible I think)
>
>The current upstream code (src/w1retap.c) uses the "__DATE__" and
>"__TIME__" GCC standard macros directly. I don't think
>dpkg-parsechangelog can affect these macros. My patch replaces these
>macros with __BUILD_DATE__.


this seems really nice and upstreamable
>The .so files are not useful or used and outside the w1retap, they are
>all internal. Thus I agree and have removed all the libw1retap*
>packages. They act more like plugins so I now have a main w1retap
>package and 5 separate plugin package for each database type.


seems better now
>There are a number of patches that I will send upstream:
>- add-etc-w1retap-conf.patch
>- movetmp.patch
>- remove-data-time-macro.patch 
>- udev rule
>- systemd service


wonderful
>I did run all of the above and found some issues. Some of the issues
>seemed to be more related to actual upstream development rather than
>packaging. Most notably predicable file creation in /tmp, which is fixed
>in the above mentioned movetmp.patch. Did you spot anything else that
>needing fixing?


mmm movetmp.patch... 

-w1->tmpname = "/tmp/.w1retap.dat";
+w1->tmpname = "/var/lib/w1retap/.w1retap.dat";


I don't think using /var/lib for tmp stuff is something 


this is a log, isn't /var/log something better?
(with some logrotate stuff)

additional little points:
- please enable hardening if possible, according to blhc 
http://debomatic-amd64.debian.net/distribution#unstable/w1retap/1.4.4-1/blhc
somebody is overriding flags

- 
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk


^^ this is useless now

- why the upstream build system is creating all this stuff in /usr/bin?
- doc might be split easily into a w1retap-doc package

usr/lib/*/w1retap/libw1common.so*
usr/lib/*/w1retap/libw1csv.so*
usr/lib/*/w1retap/libw1file.so*
usr/lib/*/w1retap/libw1serial.so*
usr/lib/*/w1retap/libw1usb.so*
usr/lib/*/w1retap/libw1xml.so*

what about a single
usr/lib/*/w1retap/lib*.so* entry?

- why systemd as runtime dependency?
- with compat 10 you can avoid --parallel and --with autoreconf

this should be enough for now (and probably now the review is complete)

last thing about your patch

-w1->rcfile = strdup("/etc/default/w1retap");
+w1->rcfile = strdup("/etc/w1retap.conf");

but you also install etc/default/w1retap... why?

G.

Bug#840818: nvidia-driver: Breaks system on a fresh installed debian; Buggy, but overwrites nouveau driver

[Domonkos Lezsák]

Package: nvidia-driver
Severity: serious
Tags: upstream
Justification: Policy 1.1

After installing nvidia-driver on a fresh installed debian (or on it's 
distributions too), the driver could not be loaded causes to boot in 
low-graphics mode.
The main problem is here, that the package overwrites the xserver-xorg-nouveau 
driver and it's hard to be restored, even purging nvidia-driver and 
reinstalling/reconfiguring xserver-xorg-nouveau. For me, a complete new Debian 
installation was the solution.
The package was working earlyer on Linux Mint Sarah, but now breaks both system.

# Hardware configuration:
Dell Precision M4600
with dual-video card:
* 1x Nvidia Quadro 2000M
* 1x Intel HD 1000 <-- Not identified by even lspci

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

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

Bug#840819: vlogger cannot load Tie::Hash::NamedCapture

[Denis Dordoigne]

Package: vlogger
Version: 1.3-3.1
Severity: normal

Dear Maintainer,

This errors frequently appears in apache2 error log :
 piped log program ' /usr/sbin/vlogger -s access.log -t "access-%Y%m%d.log" 
/var/log/alternc-awstats/' failed unexpectedly Can't locate 
Tie/Hash/NamedCapture.pm in @INC (@INC contains: /etc/perl 
/usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 
/usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 
/usr/local/lib/site_perl) at /usr/sbin/vlogger line 430,  line 1.

NamedCapture.pm is provided by perl package :
 web03 ~ # dpkg-query -L perl |grep Tie/Hash/NamedCapture.pm
 /usr/lib/perl/5.14.2/Tie/Hash/NamedCapture.pm

When I try to use Tie::Hash::NamedCapture in cannot reproduce the issue :
 web03 ~ # perl  -wM'Tie::Hash::NamedCapture' -e 'print 
"$Tie::Hash::NamedCapture::VERSION\n"'
 0.08

Could tou please identify why vlogger does not find this package ?

Thanks,

-
Denis Dordoigne
Infini

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages vlogger depends on:
ii  libtimedate-perl  1.2000-1
pn  perl  
web0y ~ # dpkg-query -L perl |grep Tie/Hash/NamedCapture.pm
/usr/lib/perl/5.14.2/Tie/Hash/NamedCapture.pm

vlogger recommends no packages.

Versions of packages vlogger suggests:
ii  libdbi-perl  1.622-1+deb7u1

e-NamedCapture.pm nl debconf information

Bug#683757: bamfdaemon: unowned directory after purge: /usr/share/applications/

[Andreas Beckmann]

Followup-For: Bug #683757
Control: severity -1 serious
Control: found -1 0.5.3-1~exp1
Control: found -1 0.5.3-1~exp2

Fixing this bug has introduced a regression:

  Removing bamfdaemon (0.5.3-1~exp2) ...
  rmdir: failed to remove '/usr/share/applications': No such file or directory
  dpkg: error processing package bamfdaemon (--remove):
   subprocess installed post-removal script returned error exit status 1

Instead of messing with that directory manually, the package
should rather ship it as an empty directory and let dpkg handle
its creation and removal.


Andreas

Bug#840762: motif: Please update to newest upstream release 2.3.6

[Graham Inggs]

Hi Joachim

On 14 October 2016 at 21:08, Joachim Wiedorn  wrote:
> After I have tested the 'enable-utf8' or better 'disable-utf8' option
> I see that utf8 was already enabled in you packages. I misunderstood some
> lines in file configure.ac and enabled utf8 again.

OK, thanks for confirming.

> While running autoreconf many Makefile.am files printed following
> warnings:
>
>   warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
>
> So I have changed in all Makefile.am files to this newer name.

This seems like a good patch to send upstream.  Would you do that please?

Regards
Graham

Bug#754920: wiki.debian.org: Access to wiki.debian.org is blocked with 403 Forbidden

[Anton Ryzhenko]

Package: wiki.debian.org
Followup-For: Bug #754920

Dear Maintainer,

It appears some of our IPs have been blocked, and we receive a 403
Forbidden when trying to reach wiki.debian.org.

$ curl -I https://wiki.debian.org/
HTTP/1.1 403 FORBIDDEN
Date: Sat, 15 Oct 2016 10:15:50 GMT
Server: Apache
Strict-Transport-Security: max-age=15552000
Public-Key-Pins: pin-sha256="yPqY/77C2aLVJIEAYtuMrFy+cX6g4CatH03gcBQbxpo=";
pin-sha256="TzmD7DK6d5d7RU66/XTJtlENSfv+i0P7x2Xmpl8uFrY="; max-age=259200
Content-Length: 166
X-Clacks-Overhead: GNU Terry Pratchett
Content-Type: text/html


Can you please unblock 85.198.130.77/24?

Thanks.



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

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

Bug#840820: linux-image-grsec-amd64 kernel break CLONE_NEWUSER / newuidmap / unprivileged lxc containers

[john]

Package: linux-image-grsec-amd64
Version: 10
Severity: normal

Dear Maintainer,

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

   I can not start lxc unprivileged container with
   linux-image-grsec-amd64 kernel (even start as root),
   The setup work very well with normal debian kernel (start as root or 
nonroot),
   I googled "grsec + newuidmap",
   look like the problem is grsec break /proc readable by other user.
   (Please correct me, if I am wrong).

   I want to know, is it possible start lxc unprivileged container with
   grsec kernel? (start as root or nonroot)
   Thanks.

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

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


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

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

Versions of packages linux-image-grsec-amd64 depends on:
ii  linux-image-4.7.0-1-grsec-amd64  4.7.5-1+grsec201609261522+1

linux-image-grsec-amd64 recommends no packages.

linux-image-grsec-amd64 suggests no packages.

-- no debconf information

Bug#840122: Info received (Bug#840122: Incorrect description in debian/copyright)

[Osamu Aoki]

Hi,

Just for the record, fossil copyright was relicensed in 2010.

When FTP master reviewed it, it was GPL.

http://fossil-scm.org/index.html/artifact/c7dd1de9f9539a5a859c2b41fe4560604a774476
https://en.wikipedia.org/wiki/Fossil_(software)#cite_note-3

Osamu

Bug#840424: Could you fix the error that is found by verilog-mode testing on Debian?

[Wilson Snyder]

>Kiwamu Okabe  writes:
>
>>Hi Wilson,
>>
>>On Sat, Oct 15, 2016 at 3:48 PM, Kiwamu Okabe  wrote:
>>> I found that! If we run "make test" on fakeroot environment, we get such 
>>> error!
>>
>>I would like to fix this problem on Debian side by running "make test"
>>on normal user.

Makes sense.  I suspect the eval is turned off as
root/fakeroot for security, however this verilog-mode test
depends on that eval feature, so obviously the test will
fail.

Bug#840821: dh-golang: Forces xz compression which is now the default

[Guillem Jover]

Package: dh-golang
Version: 1.19
Severity: wishlist
Tags: patch

Hi!

This debhelper sequence command forces the compression to xz, but that
has been the default for some time now, even Debian stable has that.
Attached a patch removing this.

Thanks,
Guillem
From bdea538d86d91f2e36cd4875344ef140f05d1f33 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 15 Oct 2016 03:38:14 +0200
Subject: [PATCH] Remove -Zxz which is the default now

---
 lib/Debian/Debhelper/Sequence/golang.pm | 5 -
 1 file changed, 5 deletions(-)

diff --git a/lib/Debian/Debhelper/Sequence/golang.pm b/lib/Debian/Debhelper/Sequence/golang.pm
index 2307c09..72e3781 100644
--- a/lib/Debian/Debhelper/Sequence/golang.pm
+++ b/lib/Debian/Debhelper/Sequence/golang.pm
@@ -5,9 +5,4 @@ use Debian::Debhelper::Dh_Lib;
 
 insert_before('dh_gencontrol', 'dh_golang');
 
-# XXX: -u is deprecated, but we cannot use “-- -Zxz” because additional command
-# options will be appended (“-O--buildsystem=golang”), resulting in
-# “dh_builddeb -- -Zxz -O--buildsystem=golang”, which fails.
-add_command_options('dh_builddeb', '-u-Zxz');
-
 1
-- 
2.9.3

Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed

[Steven Chamberlain]

Hi!

James McCoy wrote:
> That pattern continued and Vim patch 7.4.1065[0] appears to be what
> broke Vim for kFreeBSD.

Thanks for narrowing it down to that patch.  Most of it only relates
to --enable-perlinterp=dynamic and not to --enable-perlinterp[=yes] so
the changes are mostly no-ops...

What actually seems to make a difference is:

src/Makefile:
-   $(CCC) -o $@ option.c
+   $(CCC) $(LUA_CFLAGS) $(PERL_CFLAGS) $(PYTHON_CFLAGS) $(PYTHON3_CFLAGS) 
$(RUBY_CFLAGS) -o $@ option.c

where

S["PERL_CFLAGS"]=" -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-I/usr/lib/i386-kfreebsd-gnu/perl/5.24/CORE "

and -fwrapv significantly changes the code generated in
objects/option.o.  If I override that flag with -fno-wrapv:

+   $(CCC) $(LUA_CFLAGS) $(PERL_CFLAGS) -fno-wrapv $(PYTHON_CFLAGS) 
$(PYTHON3_CFLAGS) $(RUBY_CFLAGS) $(TCL_CFLAGS) -o $@ option.c

then it no longer segfaults, and all vim-gtk tests pass :)

So maybe there is a signed integer overflow in option.c (not
necessarily in code related to Perl at all).

But the linux-i386 build compiles option.c with -fwrapv, and yet it does
not segfault;  I'm not sure why.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#840342: [nvidia-legacy-304xx-driver] Confirmation

[Andreas Beckmann]

Control: retitle -1 nvidia-legacy-304xx-driver: OpenGL broken in 304.132
Control: tag -1 upstream
Control: severity -1 serious

> this, probably the best is that each one makes a manual setback to
> 304.131.8 from Snapshots.

or use 304.131-8~bpo8+2 from jessie-backports, the should work in
stretch/sid without problems.


Andreas

Bug#840820: linux-image-grsec-amd64 kernel break CLONE_NEWUSER / newuidmap / unprivileged lxc containers

[Yves-Alexis Perez]

On Sat, 2016-10-15 at 18:37 +0800, john wrote:
> I want to know, is it possible start lxc unprivileged container with
>    grsec kernel? (start as root or nonroot)
>    Thanks.

I guess you don't really mean unprivileged containers, but rather “user
namespaces”. I honestly have no idea.

Regards,
-- 
Yves-Alexis

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

Bug#840680: [pkg-gnupg-maint] Bug#840680: dirmngr: Dirmngr not always responding

[Francesco Poli]

Control: severity -1 grave


On Thu, 13 Oct 2016 19:16:56 -0400 Daniel Kahn Gillmor wrote:

> Control: tags 840680 + unreproducible moreinfo
> Control: severity 840680 important

Hello Daniel,
I am another user who's been bitten by this bug.

When the bug report severity was downgraded below the RC threshold,
apt-listbugs removed the pin on my boxes and I upgraded dirmngr.

  [UPGRADE] dirmngr:amd64 2.1.15-3 -> 2.1.15-4
  [UPGRADE] gnupg:amd64 2.1.15-3 -> 2.1.15-4
  [UPGRADE] gnupg-agent:amd64 2.1.15-3 -> 2.1.15-4

Immediately after, I was no longer able to refresh keys from the key
servers:

  $ gpg --keyserver-options no-honor-keyserver-url \
--import-options repair-pks-subkey-bug \
--refresh-keys 0x3E1C27E11F69BFFE
  ^C
  gpg: signal Interrupt caught ... exiting

I had to press [Ctrl+C] after a long wait with no output at all.

As soon as I downgraded dirmngr, everything was back to normal:

  # dpkg -i /var/cache/apt/archives/dirmngr_2.1.15-3_amd64.deb \
/var/cache/apt/archives/gnupg_2.1.15-3_amd64.deb \
/var/cache/apt/archives/gnupg-agent_2.1.15-3_amd64.deb
  [...]
  # checkrestart 
  Found 1 processes using old versions of upgraded files
  (1 distinct program)
  (1 distinct packages)
  These processes (1) do not seem to have an associated init script to restart 
them:
  dirmngr:
  5074/usr/bin/dirmngr
  # kill -TERM 5074
  # checkrestart 
  Found 0 processes using old versions of upgraded files
  $ gpg --keyserver-options no-honor-keyserver-url \
--import-options repair-pks-subkey-bug \
--refresh-keys 0x3E1C27E11F69BFFE
  gpg: removing stale lockfile (created by 5071)
  gpg: refreshing 1 key from hkp://pool.sks-keyservers.net
  gpg: key 0x3E1C27E11F69BFFE: "Francesco Poli (wintermute) 
" not changed
  gpg: Total number processed: 1
  gpg:  unchanged: 1


Please do not downgrade the severity of this bug report, until the bug
is fixed (this way apt-listbugs users will be warned about this issue
and will have an opportunity to pin the package, while waiting for a
fix).

Thanks for your time and for the great job in maintaining GnuPG in
Debian!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp08vZMVOIV8.pgp
Description: PGP signature

Bug#840822: RFP: ruby-middleman -- Build static websites with an easy-to-use framework

[Aidan Gauland]

Package: wnpp
Severity: wishlist

* Package name: ruby-middleman
  Version : 4.1.10
  Upstream Author : Thomas Reynolds 
* URL : https://middlemanapp.com/
* License : MIT
  Programming Lang: Ruby
  Description : Build static websites with an easy-to-use framework

Middleman is a Ruby framework for building static websites with HTML-templating
languages, compiled-to-CSS languages such as Sass, and compiled-to-JavaScript
languages such as CoffeeScript.  It is somewhat similar to the Python framework
Jekyll.

I think this would be useful to have packaged for Debian for greater stability
over installing via rubygems.org (which in my experience with fraught with
peril).  Packaging this for Debian will require packaging some other Ruby
"gems", as it built on top of Padrino , which is not
already in Debian.

It is a widely-used framework
, and has at least
one Debian user (myself).

Bug#840823: execnet: FTBFS (failing tests)

[Santiago Vila]

Package: src:execnet
Version: 1.4.1-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=pybuild --with python2,python3,sphinxdoc
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
I: pybuild base:184: python3.5 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build 
running build
running build_py

[... snipped ...]

testing/test_gateway.py::TestBasicGateway::test_gateway_status_no_real_channel[thread-ssh]
 SKIPPED
testing/test_gateway.py::TestBasicGateway::test_gateway_status_no_real_channel[thread-proxy]
 PASSED
testing/test_gateway.py::TestBasicGateway::test_gateway_status_busy[thread-popen]
 FAILED
=== short test summary info 
SKIP [3] /<>/testing/conftest.py:148: no python3.2 found
SKIP [3] /<>/testing/conftest.py:148: no jython found
SKIP [3] /<>/testing/conftest.py:148: no python2.6 found
SKIP [3] /<>/testing/conftest.py:148: no pypy found
SKIP [3] /<>/testing/conftest.py:148: no python3.3 found
SKIP [36] /usr/lib/python2.7/dist-packages/_pytest/config.py:1142: no 'gspecs' 
option found

=== FAILURES ===
___ TestBasicGateway.test_gateway_status_busy[thread-popen] 

self = 
gw = 

def test_gateway_status_busy(self, gw):
numchannels = gw.remote_status().numchannels
ch1 = gw.remote_exec("channel.send(1); channel.receive()")
ch2 = gw.remote_exec("channel.receive()")
ch1.receive()
status = gw.remote_status()
assert status.numexecuting == 2  # number of active execution threads
assert status.numchannels == numchannels + 2
ch1.send(None)
ch2.send(None)
ch1.waitclose()
ch2.waitclose()
for i in range(10):
status = gw.remote_status()
if status.numexecuting == 0:
break
else:
>   pytest.fail("did not get correct remote status")
E   Failed: did not get correct remote status

testing/test_gateway.py:88: Failed
 pytest-warning summary 
WI1 /<>/testing/conftest.py:21 'pytest_runtest_setup' hook uses 
deprecated __multicall__ argument
WC1 None pytest_funcarg__specsocket: declaring fixtures using 
"pytest_funcarg__" prefix is deprecated and scheduled to be removed in pytest 
4.0.  Please remove the prefix and use the @pytest.fixture decorator instead.
WC1 None pytest_funcarg__specssh: declaring fixtures using "pytest_funcarg__" 
prefix is deprecated and scheduled to be removed in pytest 4.0.  Please remove 
the prefix and use the @pytest.fixture decorator instead.
 Interrupted: stopping after 1 failures 
= 1 failed, 135 passed, 51 skipped, 3 pytest-warnings in 8.69 seconds ==
E: pybuild pybuild:276: test: plugin custom failed with: exit code=2: python2.7 
-m pytest -v -x -rs testing/
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 returned 
exit code 13
debian/rules:8: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
debian/rules:5: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The relevant part of the build log is included above.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

Thanks.

Bug#840824: ruby-text-table: FTBFS (failing tests)

[Santiago Vila]

Package: src:ruby-text-table
Version: 1.2.4-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_testdir -i -O--buildsystem=ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby

[... snipped ...]

  1) Text::Table table-wide alignment of rows 
 # Not yet implemented
 # ./spec/integration/alignment_spec.rb:174

  2) Text::Table table-wide alignment of headers 
 # Not yet implemented
 # ./spec/integration/alignment_spec.rb:178

  3) Text::Table table-wide alignment of footers 
 # Not yet implemented
 # ./spec/integration/alignment_spec.rb:182

  4) Text::Table rows with unequal number of cells 
 # Not yet implemented
 # ./spec/integration/parts_spec.rb:27

Failures:

  1) Text::Table::Cell should return correct column index
 Failure/Error: @table.text_table_rows.first.cells[2].column_index.should 
== 3

   expected: 3
got: 2 (using ==)
 # ./spec/cell_spec.rb:20:in `block (2 levels) in '

Deprecation Warnings:

Requiring `rspec/autorun` when running RSpec via the `rspec` command is 
deprecated. Called from /<>/spec/spec_helper.rb:5:in `'.

Using `should` from rspec-expectations' old `:should` syntax without explicitly 
enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly 
enable `:should` with `config.expect_with(:rspec) { |c| c.syntax = :should }` 
instead. Called from /<>/spec/cell_spec.rb:10:in `block (2 levels) 
in '.


If you need more of the backtrace for any of these deprecations to
identify where to make the necessary changes, you can configure
`config.raise_errors_for_deprecations!`, and it will turn the
deprecation warnings into errors, giving you the full backtrace.

2 deprecation warnings total

Finished in 0.05929 seconds (files took 0.12143 seconds to load)
47 examples, 1 failure, 4 pending

Failed examples:

rspec ./spec/cell_spec.rb:17 # Text::Table::Cell should return correct column 
index

/usr/bin/ruby2.3 /usr/bin/rspec ./spec/cell_spec.rb ./spec/enumerable_spec.rb 
./spec/integration/alignment_spec.rb ./spec/integration/boundaries_spec.rb 
./spec/integration/column_spans_spec.rb ./spec/integration/parts_spec.rb failed
ERROR: Test "ruby2.3" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-text-table 
returned exit code 1
debian/rules:15: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


The relevant part of the build log is included above.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

Thanks.

Bug#840354: src:pcre3: FTBFS on powerpc (G4 CPU)

[Matthew Vernon]

Hi,




As a hopefully temporary workaround you could disable jit for powerpc,
of course a the cost of a performance penalty.


Thanks for the bug report; I've raised it with upstream, and we'll see 
what they say. If it gets to the point where you feel "let's stop 
waiting for upstream, and put in a disable-jit patch temporarily" then 
do shout.


Regards,

Matthew

Bug#840818: nvidia-driver: Breaks system on a fresh installed debian; Buggy, but overwrites nouveau driver

[Luca Boccassi]

Control: severity -1 normal

On Sat, 2016-10-15 at 12:15 +0200, Domonkos Lezsák wrote:
> Package: nvidia-driver
> Severity: serious
> Tags: upstream
> Justification: Policy 1.1

No, it's not. If this is an issue, it is _very_ specific to one type of
machine. It is not a general issue with the packages.

> After installing nvidia-driver on a fresh installed debian (or on it's 
> distributions too), the driver could not be loaded causes to boot in 
> low-graphics mode.

Without kernel and xorg logs it's impossible to tell what the problem
is.

> The main problem is here, that the package overwrites the 
> xserver-xorg-nouveau driver and it's hard to be restored, even purging 
> nvidia-driver and reinstalling/reconfiguring xserver-xorg-nouveau. For me, a 
> complete new Debian installation was the solution.

It does not overwrite nouveau, it blacklists it, and that's working as
intended as the proprietary modules and the nouveau modules are mutually
exclusive.

> The package was working earlyer on Linux Mint Sarah, but now breaks both 
> system.
> 
> # Hardware configuration:
> Dell Precision M4600
> with dual-video card:
> * 1x Nvidia Quadro 2000M
> * 1x Intel HD 1000 <-- Not identified by even lspci

I can only find conflicting information online, some say that laptop is
an optimus system, some say it isn't.
You should check your BIOS, make sure it is up to date, and check if
there are optimus or switchable graphics options.

If it is an optimus system, you must install bumblebee-nvidia, and then
the Intel card will be used as the main gpu and you can use the discrete
one via optirun.

https://wiki.debian.org/Bumblebee

If it is not an optimus system, then it most likely has a switch in the
bios to decide which card to use. Or it could be hardcoded to always use
the nvidia one. In this case it is very much dependent on the specific
hardware.

Kind regards,
Luca Boccassi


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

Bug#840825: libtag1-dev: missing header files

[James Cowgill]

Package: libtag1-dev
Version: 1.11+dfsg.1-0.1
Severity: serious
Control: affects -1 kid3
X-Debbugs-CC: m...@lm7.fr

Hi,

taglib 1.11+dfsg.1-0.1 and 1.11+dfsg.1-0.2 are missing various include
files which should be shipped in /usr/include. These are reported by
dh_install:

dh_install --list-missing
dh_install: usr/include/taglib/podcastframe.h exists in debian/tmp but
is not installed to anywhere
dh_install: usr/include/taglib/tableofcontentsframe.h exists in
debian/tmp but is not installed to anywhere
dh_install: usr/include/taglib/eventtimingcodesframe.h exists in
debian/tmp but is not installed to anywhere
dh_install: usr/include/taglib/chapterframe.h exists in debian/tmp but
is not installed to anywhere
dh_install: usr/include/taglib/synchronizedlyricsframe.h exists in
debian/tmp but is not installed to anywhere

This at least breaks kid3 which uses these headers if taglib is new
enough. Can I also suggest enabling "dh_install --fail-missing" so this
doesn't happen again :)

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#840501: transition: ipython: tried building glueviz and vistrails

[Tobias Hansen]

Hi,

I checked that glueviz and vistrails also can be built against the new
versions of ipython and python-qtconsole. So the only obvious blockers
now are the FTBFS of yade and that plotly depends on ipython-notebook.

Best,
Tobias

Bug#840744: [pkg-go] Bug#840744: golang-dns: Packaging cleanups and new upstream release

[Guillem Jover]

Hi!

On Sat, 2016-10-15 at 02:54:01 +0200, Martín Ferrari wrote:
> On 14/10/16 22:18, Guillem Jover wrote:
> >> Here's a packaging cleanup and new upstream release request. (This one
> >> I also had packaged initially from scratch as I didn't find it :/.)
> >>
> >> Attached the working and tested patch. I've also renamed the Vcs
> >> fields to makes this less confusing overall, but that will require
> >> changes on the alioth side (probably rename + compat symlinks?).
> > 
> > Hmm, it seems that particular iteration was not working so much. :/
> > Attached a fixed version. With additional cleanups.
> 
> I merged this partially, and renamed the repo. There are some changes
> that I think are not correct:
> 
> * We are not using built-using in -dev packages any more. Somebody
> explained to me the reason for this, but I forgot :-)

Indeed, that does not make sense, because the -dev do not embed
anything from the built-using packages. They are only used for testing
purposes. As I mentioned on IRC I would swear I saw a warning about
this, but it seems I was wrong, and probably too tired. I'll go over
all submitted packaging and recheck them just in case.

> * I think the usage of _build as build directory is not needed.

I found it prettier to have the build directory not change depending
on the host. And because it's easier to deal with when debugging or
similar, the instructions are just “go check the built stuff under
_build”.

> * The old upstream name was wrong, and I don't think we have set a
> standard for this, but I usually use the import path for this.

I'm assuming we are talking about the Upstream-Name field here. In
which case I think I've mostly seen the repo name used in many other
golang packages. I thought about using the import path but that seems
redundant with the Source field?

> Also, you forgot to close the bug in the changelog :)

On the second iteration yes, on the first it didn't exist yet. ;)

> So, before I upload, let's discuss those pending changes.

It seems you might need to update to a new upstream snapshot too. :)

> PS: I also added a couple more cleanups.

Yeah, I've seen, thanks!

Regards,
Guillem

Bug#826165: Another confirm on different OS

[Georgi D. Sotirov]

Hello,

I confirm the same problem with OpenSC 0.16 under Slackware Linux (see 
below). I stumbled upon this bug and I'd like to know whether it was 
reported upstream or not, because unfortunately there is no new release 
of OpenSC since June .


   $ pkcs11-tool --module /usr/lib64/onepin-opensc-pkcs11.so -t -l
   Using slot 0 with a present token (0x0)
   Logging in to "InfoNotary (PIN)".
   Please enter User PIN:
   C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  seems to be OK
   Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
   Signatures (currently only RSA signatures)
  testing key 0 (99D807BB-9D5A-4345-8D18-8B831BB5D178)
   error: PKCS11 function C_SignFinal failed: rv = CKR_GENERAL_ERROR (0x5)

   Aborting.



Best Regards,
--

*Georgi D. Sotirov*
Software Developer

<>

Bug#840826: princeprocessor: /usr/bin/pp64 is already used by polylib-utils

[Andreas Beckmann]

Package: princeprocessor
Version: 0.21-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

  Selecting previously unselected package princeprocessor.
  Preparing to unpack .../princeprocessor_0.21-2_amd64.deb ...
  Unpacking princeprocessor (0.21-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/princeprocessor_0.21-2_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/pp64', which is also in package polylib-utils 
5.22.5-3+dfsg
  Errors were encountered while processing:
   /var/cache/apt/archives/princeprocessor_0.21-2_amd64.deb

Probably the newly introduced packages should rename that binary.


cheers,

Andreas

Bug#840827: lucene-solr: FTBFS (failing tests, no route to host)

[Santiago Vila]

Package: src:lucene-solr
Version: 3.6.2+dfsg-8
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with maven_repo_helper
   dh_testdir -i
   dh_update_autotools_config -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/lucene-solr-3.6.2+dfsg'
# Link in jars from /usr/share/java rather
# than patching the build process
for pkg in `cat debian/build-jars`; \
do \
ln -sf `echo $pkg | cut -d : -f 1` `echo $pkg | cut -d : -f 2`; \
done
ln: failed to create symbolic link './lucene/lib/ant.jar': No such file or 
directory

[... snipped ...]

[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:535)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1182)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1033)
[junit] Caused by: java.net.NoRouteToHostException: No route to host
[junit] at java.net.PlainSocketImpl.socketConnect(Native Method)
[junit] at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
[junit] at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
[junit] at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
[junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[junit] at java.net.Socket.connect(Socket.java:589)
[junit] at java.net.Socket.connect(Socket.java:538)
[junit] at java.net.Socket.(Socket.java:434)
[junit] at java.net.Socket.(Socket.java:211)
[junit] at 
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
[junit] at 
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
[junit] at 
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
[junit] ... 44 more
[junit] 
[junit] 
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5.301 sec
[junit] 
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test 
-Dtestcase=TestRemoteCachingWrapperFilter -Dtestmethod=testTermRemoteFilter 
-Dtests.seed=360d91d04c9e1cb5:-d1bf13dc331d343:-5a995359e653cf8b 
-Dargs="-Dfile.encoding=ANSI_X3.4-1968"
[junit] NOTE: reproduce with: ant test 
-Dtestcase=TestRemoteCachingWrapperFilter -Dtestmethod=testTermRemoteFilter 
-Dtests.seed=360d91d04c9e1cb5:-d1bf13dc331d343:-5a995359e653cf8b 
-Dargs="-Dfile.encoding=ANSI_X3.4-1968"
[junit] NOTE: test params are: locale=it, timezone=Pacific/Enderbury
[junit] NOTE: all tests run in this JVM:
[junit] [TestRemoteCachingWrapperFilter]
[junit] NOTE: Linux 4.7.0-1-amd64 amd64/Oracle Corporation 1.8.0_102 
(64-bit)/cpus=1,threads=1,free=86734984,total=95354880
[junit] -  ---
[junit] Test org.apache.lucene.search.TestRemoteCachingWrapperFilter FAILED

BUILD FAILED
/<>/lucene-solr-3.6.2+dfsg/lucene/build.xml:584: The following error 
occurred while executing this line:
/<>/lucene-solr-3.6.2+dfsg/lucene/common-build.xml:1051: The 
following error occurred while executing this line:
/<>/lucene-solr-3.6.2+dfsg/lucene/contrib/contrib-build.xml:61: The 
following error occurred while executing this line:
/<>/lucene-solr-3.6.2+dfsg/lucene/common-build.xml:692: 
The following error occurred while executing this line:
/<>/lucene-solr-3.6.2+dfsg/lucene/common-build.xml:676: Tests failed!
The following error occurred while executing this line:
/<>/lucene-solr-3.6.2+dfsg/lucene/common-build.xml:676: Tests failed!
The following error occurred while executing this line:
/<>/lucene-solr-3.6.2+dfsg/lucene/common-build.xml:676: Tests failed!
The following error occurred while executing this line:
/<>/lucene-solr-3.6.2+dfsg/lucene/common-build.xml:676: Tests failed!

Total time: 10 minutes 58 seconds
debian/rules:31: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>/lucene-solr-3.6.2+dfsg'
debian/rules:8: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The build was made in a KVM/QEMU virtual machine with 1 CPU using sbuild.

I attach a full build log, but the build system leaks the IP of the machine
(it probably shouldn't). I've redacted that.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible

Bug#577737: [pinentry-qt4] Re: gpg command won't use agent if the agent is configured to use pinentry-qt4

[OmegaPhil]

On 15/10/16 01:45, Daniel Kahn Gillmor wrote:
> On Fri 2016-10-14 16:56:37 -0400, OmegaPhil wrote:
>> On 14/10/16 00:28, Daniel Kahn Gillmor wrote:
>>> On Thu 2016-10-13 14:09:16 -0400, OmegaPhil wrote:
 As soon as I did a killall to have gpg-agent load the new
 configuration and try again, it worked - I know that gpg2 stuff has
 updated recently, and my uptime is ~11d, so perhaps the update scripts
 don't kill off gpg-agent when theres some incompatible change?
>>>
>>> That's right, the package upgrade scripts make no attempt to restart
>>> long-running user processes, for reasons i suspect you can imagine :)
>>>
>>> Can you review /var/log/dpkg.log to see what versions of gpg-agent you
>>> might have been running initially?  I'm glad it's working for you now,
>>> anyway, though i'm still in the dark as to why it wasn't working for you
>>> before.
>>
>> Latest mentions of gnupg-agent:
>>
>> =
>>
>> /var/log/dpkg.log:2016-10-02 08:11:27 upgrade gnupg-agent:amd64 2.1.11-7 
>> 2.1.15-3
> 
> You wrote ~11d on the 13th.  This upgrade is from the 2nd, ~11d before
> the report.  Can you tell me whether this upgrade happend before or
> after the boot that led you into the 11d uptime?  If it happened after
> then yes, you were most likely running the older gpg-agent without
> restarting it, which would explain the failures you saw.
> 
> fwiw, gpg should provide warning messages to stderr if it discovers it's
> talking to an older agent, but if you only accessed it through enigmail
> maybe those warning messages weren't propagated through to where you
> could easily see them.
> 
>--dkg


No, 'old gpg-agent was running' doesn't seem to be the right explanation
for this. The upgrade happened at 2016-10-02 08:11:27, however October
the 2nd looks like monthly reboot day, since there was a reboot from a
v4.5 kernel into v4.6 at 19:35:49, and then v4.7 at 19:40:19 (I'm
running v4.7.5-1 atm).

I'd like to say that any complaints from gpg-agent would cause that
Enigmail dialog to pop up, e.g. the 4 repeats of the dialog originally
suggestively match the 4 lines reported to .xsession-errors.



signature.asc
Description: OpenPGP digital signature

Bug#840828: tigervnc-viewer: leaves alternatives after purge: /usr/bin/{,x}vncviewer

[Andreas Beckmann]

Package: tigervnc-viewer
Version: 1.6.0+dfsg-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

While there is ongoing discussion how to remove alternatives correctly
(see https://bugs.debian.org/71621 for details) the following strategy
should work for regular cases:
* 'postinst configure' always installs the alternative
* 'prerm remove' removes the alternative
* 'postrm remove' and 'postrm disappear' remove the alternative
In all other cases a maintainer script is invoked (e.g. upgrade,
deconfigure) the alternatives are not modified to preserve user
configuration.
Removing the alternative in 'prerm remove' avoids having a dangling link
once the actual file gets removed, but 'prerm remove' is not called in
all cases (e.g. unpacked but not configured packages or disappearing
packages) so the postrm must remove the alternative again
(update-alternatives gracefully handles removal of non-existing
alternatives).

Note that the arguments for adding and removing alternatives differ, for
removal it's 'update-alternatives --remove  '.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m27.9s INFO: Warning: Package purging left files on system:
  /etc/alternatives/vncviewer -> /usr/bin/xtigervncviewernot owned
  /etc/alternatives/vncviewer.1.gz -> /usr/share/man/man1/xtigervncviewer.1.gz  
 not owned
  /etc/alternatives/xvncviewer -> /usr/bin/xtigervncviewer   not owned
  /etc/alternatives/xvncviewer.1.gz -> /usr/share/man/man1/xtigervncviewer.1.gz 
 not owned
  /usr/bin/vncviewer -> /etc/alternatives/vncviewer  not owned
  /usr/bin/xvncviewer -> /etc/alternatives/xvncviewernot owned
  /usr/share/man/man1/vncviewer.1.gz -> /etc/alternatives/vncviewer.1.gz
 not owned
  /usr/share/man/man1/xvncviewer.1.gz -> /etc/alternatives/xvncviewer.1.gz  
 not owned


cheers,

Andreas


tigervnc-viewer_1.6.0+dfsg-2.log.gz
Description: application/gzip

Bug#840788: vtk6: Change libmysqlclient-dev build dependency to default-libmysqlclient-dev

[Andreas Beckmann]

On Fri, 14 Oct 2016 23:44:15 +0200 Bas Couwenberg 
wrote:
> Please change the libmysqlclient-dev build dependency to
> default-libmysqlclient-dev. The vtk6 build dependencies are
> no longer installable now that libgdal-dev depends on
> default-libmysqlclient-dev which is not co-installable with
> libmysqlclient-dev.

There is also a dependency libvtk6-dev -> libmysqlclient-dev which
renders the package uninstallable in sid.


Andreas

Bug#840829: docker.io: Won't start under cgroupsv2

[Sam Morris]

Package: docker.io
Version: 1.11.2~ds1-6
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When booting with the systemd.unified_cgroup_hierarchy kernel parameter,
systemd mounts the cgroup2 filesystem at /sys/fs/cgroup. As a result,
docker no longer starts:

time="2016-10-13T11:40:35.542974438+01:00" level=info msg="New containerd 
process, pid: 5361\n"
time="2016-10-13T11:40:36.560787581+01:00" level=info msg="[graphdriver] using 
prior storage driver \"overlay\""
time="2016-10-13T11:40:36.589298060+01:00" level=info msg="Graph migration to 
content-addressability took 0.00 seconds"
time="2016-10-13T11:40:36.641136232+01:00" level=info msg="Firewalld running: 
false"
time="2016-10-13T11:40:36.769321694+01:00" level=info msg="Default bridge 
(docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can 
be used to set a preferred IP address"
time="2016-10-13T11:40:36.930907456+01:00" level=warning msg="Your kernel does 
not support cgroup memory limit"
time="2016-10-13T11:40:36.930946129+01:00" level=warning msg="Unable to find 
cpu cgroup in mounts"
time="2016-10-13T11:40:36.930958093+01:00" level=warning msg="Unable to find 
blkio cgroup in mounts"
time="2016-10-13T11:40:36.930967804+01:00" level=warning msg="Unable to find 
cpuset cgroup in mounts"
time="2016-10-13T11:40:36.933815046+01:00" level=warning msg="mountpoint for 
pids not found"
time="2016-10-13T11:40:36.934330952+01:00" level=fatal msg="Error starting 
daemon: Devices cgroup isn't mounted"

- -- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (550, 'testing-debug'), (550, 'testing'), (520, 
'unstable-debug'), (520, 'unstable'), (510, 'experimental-debug'), (510, 
'experimental')
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-

iQIvBAEBCAAZBQJYAhT8EhxzYW1Acm9ib3RzLm9yZy51awAKCRDSC0ICXNonuROt
D/wO0othjFHjaLx5vN8WoMezgHsssCM5TFAtmrOiON2kZOmgM4o5QHM0SHG9w+RQ
WEVAwjPttfKPFz9NnYM8Pbj8eJWL8j0MRfUnB88HxakjdxTViktIgoOcDjIoD48X
kbkK+TJi1DmQCSNzdNXkGxZRCgQUNVaxFVSrWkUDYoPg7QTO/B98/GK+s1mDVn4p
yJJoB9sEa7uO1XtiMvRj4CeXymmFpG7RSpzn1XC6XZ7w344B6FfSkK2Pbj5MAhla
nGorZsdrgzRmwI2F1s0xdVKWxsjwWJKGK5qK0fX6ax4Fv1s8ZL0DzUNwG3xws0su
c9K9F81qyrfLwl+KrfqYtk067KLYo2cpm0ppcgqNmNVpwcKwku+Vx8A/0QX2Jn+r
BgMpDmaH9WRrcb07Gy33bEYFrAS9lLGTfyxw8EyeETncfrPkWeIo5suUylEuuL1s
Z1xQqk2WR2wKl7pXoCc0K4ZW2h2g/IsbF+W65AKlorKGRCV922oWrZw1kDAVCt1H
WSQqLfJi12ofNehaB3JDpkf3oLEDrgTClodKmx2uvAJZRdfuGjcsN9OTjGWv84gx
aPaIPYba5JwjrCZy8ofx7OxCVFU8D61W3wJ74YXwNcan7TvLW1ckXRg+F9auHDYc
UQiPwQ+asnk4m3xGGEtioGuy7heF2iqJjgKe9MJ5c6UcLg==
=0FE4
-END PGP SIGNATURE-

Bug#840826: princeprocessor: /usr/bin/pp64 is already used by polylib-utils

[Sascha Steinbiss]

Hi Andreas,

thanks for noticing this and letting me know. I will make sure to rename the 
single binary in this package to avoid the name clash.

Cheers
Sascha

> On 15 Oct 2016, at 13:22, Andreas Beckmann  wrote:
> 
> Package: princeprocessor
> Version: 0.21-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install
> because it tries to overwrite other packages files.
> 
>  Selecting previously unselected package princeprocessor.
>  Preparing to unpack .../princeprocessor_0.21-2_amd64.deb ...
>  Unpacking princeprocessor (0.21-2) ...
>  dpkg: error processing archive 
> /var/cache/apt/archives/princeprocessor_0.21-2_amd64.deb (--unpack):
>   trying to overwrite '/usr/bin/pp64', which is also in package polylib-utils 
> 5.22.5-3+dfsg
>  Errors were encountered while processing:
>   /var/cache/apt/archives/princeprocessor_0.21-2_amd64.deb
> 
> Probably the newly introduced packages should rename that binary.
> 
> 
> cheers,
> 
> Andreas
> 
> 

Bug#840830: mark gnome-mime-data Multi-Arch: foreign

[Helmut Grohne]

Package: gnome-mime-data
Version: 2.18.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:gnome-vfs

gnome-vfs cannot be cross built from source, because its build
dependency on gnome-mime-data is unsatisfiable. In general, dependencies
on Architecture: all packages are cross unsatisfiable unless they are
marked Multi-Arch: foreign.

In this case, the marking looks correct, because gnome-mime-data is
Architecture: all and doesn't have any maintainer scripts or
dependencies. Please consider applying the attached patch.

Helmut
diff -u gnome-mime-data-2.18.0/debian/control 
gnome-mime-data-2.18.0/debian/control
--- gnome-mime-data-2.18.0/debian/control
+++ gnome-mime-data-2.18.0/debian/control
@@ -10,6 +10,7 @@
 Package: gnome-mime-data
 Architecture: all
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Multi-Arch: foreign
 Description: base MIME and Application database for GNOME.
  This module contains the base MIME and Application database for GNOME.
  It is meant to be accessed through the MIME functions in GnomeVFS.
diff -u gnome-mime-data-2.18.0/debian/changelog 
gnome-mime-data-2.18.0/debian/changelog
--- gnome-mime-data-2.18.0/debian/changelog
+++ gnome-mime-data-2.18.0/debian/changelog
@@ -1,3 +1,10 @@
+gnome-mime-data (2.18.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 15 Oct 2016 13:36:21 +0200
+
 gnome-mime-data (2.18.0-1) unstable; urgency=low
 
   * Add a get-orig-source target to retrieve the upstream tarball.

Bug#840827: lucene-solr: FTBFS (failing tests, no route to host)

[Santiago Vila]

I forgot to tell that I can reproduce this only on some machines but
not in others. The machines on which it fails (there are more than one)
seem to be the ones having some corporate firewall rules I can't
disable. This is probably not just a coincidence.

However, since packages are not supposed to use the network during the build,
a bad network configuration should never make the package to FTBFS anyway.

Thanks.

Bug#840473: cfitsio: new upstream version

[Aurelien Jarno]

On 2016-10-13 08:52, Ole Streicher wrote:
> Aurelien Jarno:
> > Florian Schlichting:
> >> a new upstream version of cfitsio was released in April 2016. Would you
> >> consider packaging it?
> > 
> > Yes, I am aware of that. Unfortunately it introduces yet another soname
> > changes, which make things a bit more complicated.
> 
> Since there is a transition freeze effective from 2016-11-05 [1], this
> should IMO be addressed ASAP. For the packages under Debian Astro
> maintenance, I could offer help here.

I agree we that if we want to get it in Stretch, it has to be done ASAP.
That said it's a minor release, without that many changes, despite the
ABI breakage :(.

I have just uploaded the new version to experimental.

> Could you specify where you expect the complications?

I haven't been able to test rebuild all the reverse dependencies yet, so
they are not yet known.

> BTW, I would recommend to put cfitsio under Debian Astro team
> maintenance, due to the importance of the package. Would you be willing
> to do that?

Please give me access to the project, I'll commit it there.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#835293: Log file shows additional information

[Andreas Cadhalpun]

Control: tags -1 moreinfo

Hi Gavin,

On 24.08.2016 13:01, Gavin Donald wrote:
> I am not sure if this is relevant but reinstalling clamav-daemon
> (for the third time) shows the following log file entry:

Reinstalling causes the config script to run, so the configured
TCP socket should have worked at that point.

> LOCAL: No local AF_UNIX SOCK_STREAM socket received from systemd

This is expected if you're only using a TCP socket.

> Looking at this report:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771911
> 
> suggests that /etc/systemd/system/clamav-daemon.socket.d/extend.conf should 
> contain:
> 
> [Socket]
> ListenStream=127.0.0.1:3310
> 
> Mine contains:
> 
> [Socket]
> ListenStream=
> SocketUser=clamav
> ListenStream=127.0.0.1:3310
> 
> Which seems similar enough.

That is good and should work. Does it not?

What is the output of:
$ sudo systemctl status clamav-daemon

Best regards,
Andreas

Bug#840831: libvirtuoso5.5-cil: fails to install: E: installing Assembly /usr/lib/cli/virtuoso-5.5/OpenLink.Data.Virtuoso.dll failed

[Andreas Beckmann]

Package: libvirtuoso5.5-cil
Version: 6.1.6+dfsg2-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libvirtuoso5.5-cil.
  (Reading database ... 
(Reading database ... 7366 files and directories currently installed.)
  Preparing to unpack .../libvirtuoso5.5-cil_6.1.6+dfsg2-3+b1_amd64.deb ...
  Unpacking libvirtuoso5.5-cil (6.1.6+dfsg2-3+b1) ...
  Setting up libvirtuoso5.5-cil (6.1.6+dfsg2-3+b1) ...
  * Installing 1 assembly from libvirtuoso5.5-cil into Mono
  E: installing Assembly /usr/lib/cli/virtuoso-5.5/OpenLink.Data.Virtuoso.dll 
failed
  E: Installation of libvirtuoso5.5-cil with 
/usr/share/cli-common/runtimes.d/mono failed
  dpkg: error processing package libvirtuoso5.5-cil (--configure):
   subprocess installed post-installation script returned error exit status 29
  Errors were encountered while processing:
   libvirtuoso5.5-cil

cheers,

andreas


libvirtuoso5.5-cil_6.1.6+dfsg2-3+b1.log.gz
Description: application/gzip

Bug#767006: AW: Goodnews

[Kemmer, Elmar]

?


Von: Kemmer, Elmar
Gesendet: Samstag, 15. Oktober 2016 13:40
An: Kemmer, Elmar
Betreff: Goodnews


I, Liliane Donated 2,000,000 Dollars to you, Contact me on ( 
lbettencour...@hotmail.com ) for more details??

Bug#840832: galileo-daemon: fails to purge: deluser options need perl-modules to be installed

[Andreas Beckmann]

Package: galileo-daemon
Version: 0.5.1-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to purge.
According to policy 7.2 you cannot rely on the depends being available
during purge, only the essential packages are available for sure.

Filing this as important because a.) it's a clear policy violation (to
not clean up at purge) b.) having a piuparts clean archive is a release
goal since lenny and c.) this package being piuparts buggy blocks
packages depending on it from being tested by piuparts (and thus
possibly the detection of more severe problems).

>From the attached log (scroll to the bottom...):

1m25.2s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmp5D7IYJ', 'dpkg', 
'--purge', 'galileo-daemon']
1m25.7s DUMP: 
  (Reading database ... 4408 files and directories currently installed.)
  Removing galileo-daemon (0.5.1-1) ...
  Purging configuration files for galileo-daemon (0.5.1-1) ...
  /usr/sbin/deluser: In order to use the --remove-home, --remove-all-files, and 
--backup features,
  you need to install the `perl-modules' package. To accomplish that, run
  apt-get install perl-modules.
  dpkg: error processing package galileo-daemon (--purge):
   subprocess installed post-removal script returned error exit status 8
  Errors were encountered while processing:
   galileo-daemon
1m25.7s DEBUG: Command failed (status=1), but ignoring error: ['chroot', 
'/tmp/piupartss/tmp5D7IYJ', 'dpkg', '--purge', 'galileo-daemon']


cheers,

Andreas


galileo-daemon_0.5.1-1.log.gz
Description: application/gzip

Bug#837917: Solution found

[Werner Mahr]

Hi,

as I ran into the same problem, I first searched for the rar-mimetype in 
systemsettings.

rar is known there as application/vnd.rar
but in plugins/clirarplugin/kerfuffle_clirar.json everything refers to 
application/x-rar

After adjusting this setting and recompiling, everything worked like always.

I just don't know, if the mimetypes or ark uses an older setting for this.

-- 
MfG. usw.

Werner Mahr

Bug#840833: avahi-autoipd: manpage refers to nonexisting autoipd.action(8)

[Jari Aalto]

Package: avahi-autoipd
Version: 0.6.32-1
Severity: minor

Command:

man avahi-autoipd

in "SEE ALSO", refers to non exiting manual page:

autoipd.action(8)

There is however page:

avahi-autoipd.action(8)

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

Kernel: Linux 3.2.0-4-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)

Bug#838430: volti: traceback on startup

[Toni Mueller]

Hi James,

On Sat, Sep 24, 2016 at 01:33:59PM +0800, Toni Mueller wrote:
> On Wed, Sep 21, 2016 at 10:19:28AM +0100, James Cowgill wrote:
> > You could try this:
> > sed -i 's/card_index = 0/card_index = 1/' ~/.config/volti/config
> 
> it worked!

just as another data point: Today, I've tried the same on Jessie with a
the 4.7 kernel from backports, but the result is this:

$ volti
[alsactrl.py:__init__:41] can't open Master control for card PCH, trying to 
select first available mixer channel

[alsactrl.py:__init__:49] can't open first available control for card PCH
error: list index out of range
Xlib.protocol.request.QueryExtension
Traceback (most recent call last):
  File "/usr/bin/volti", line 53, in 
volti = main.VolumeTray()
  File "/usr/lib/volti/volti/main.py", line 124, in __init__
self.watchid = gobject.io_add_watch(fd, eventmask, self.update)
TypeError: an integer is required
$ 

It looks like the Pulseaudio system does not find the card, and volti
subsequently barfs.


Cheers,
--Toni++

Bug#840400: debian-installer: Installation fails at Partitioning on EFI with vfat filesystem

[Stephan Dollberg]

On Tue, 11 Oct 2016 14:24:02 +0530 Mohammed Sadiq  wrote:
> Package: debian-installer
> Severity: important
>
> Debian testing installation (From DVD-1) fails at Partitioning:
>
> The following error is reported:
>
> The attempt to mount a file system with type vfat in SCSI1(0, 0, 0),
partition #2 (sda) at /boot/efi failed.
>
> You may resume partitioning from the partitioning menu.
> Do you want to resume partitioning?
>  
>
> (Above log may contain typos, sorry.)
>
> If I select  Installer yells at me saying "An installation step
failed" and Aborts.
>
>
> When I try to mount /dev/sda2 manually (mount /dev/sda2 /mnt). It says
"... failed. Invalid argument".
> /dev/sda2 is shown as 'EFI System Partition' in Partition lists of the
installer.
>
> So probably the vfat module for mount is missing (or not loaded by
default) in installer, which should be.
>
> The system is booted with EFI mode enabled (and secure boot disabled).
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
>

Hello,

I faced the same problem yesterday. In addition to what Mohammed mentioned,
I also saw messages about the installer trying to use `stat` which is not
available.

Maybe this helps.

Stephan

Bug#840246: RFP: krita -- Krita is a professional FREE and open source painting program.

[Boyuan Yang]

X-Debbugs-CC: debian-de...@lists.debian.org
X-Debbugs-CC: debian-qt-...@lists.debian.org

> Package: wnpp
> Severity: wishlist
>
> * Package name: krita
>   Version : 3.0
>   Upstream Author : Boudewijn Rempt  and others
> * URL : https://krita.org
> * License : GPL2+, LGPL2+
>   Programming Lang: C++
>   Description : Krita is a professional FREE and open source painting
program.

https://ftp-master.debian.org/new/krita_1:3.0.1+dfsg-1.html

Due to BD-missing in ports architecture for calligra 2.9 [1], the old
calligra 2.8 still has leftovers.

What would happen if krita 3.x gets accepted into experimental while
old calligra-owned krita still exists? :p

Anyway I also hope that this problem can be solved soon and we get
krita 3.x into stretch.


[1] https://buildd.debian.org/status/package.php?p=calligra


--
Regards,
Boyuan Yang

Bug#839190:

[LAGOLI WARLORD]

hello dearest

Bug#840835: harvid: ffmpeg not found

[Arturo Borrero Gonzalez]

Package: harvid
Version: 0.8.1-2+b2
Severity: normal

Thanks for your work with this package, it's really appreciated.

Today, I tried to import a video in ardour following this method:

 * opened ardour
 * session -> open video
 * it then asked me to install harvid
 * installed harvid via aptitude
 * tried again session -> open video
 * a dialog to choose the video to import
 * Then Ardour, in a windows called "Transcode/Import video file" says:

ffmpeg not found. Unable to import video.

However:

% dpkg -s ffmpeg
Package: ffmpeg
Status: install ok installed
Priority: optional
Section: video
Installed-Size: 1983
Maintainer: Debian Multimedia Maintainers 

Architecture: amd64
Multi-Arch: foreign
Version: 7:3.0.2-4
Replaces: libav-tools (<< 6:12~~), qt-faststart (<< 7:2.7.1-3~)
Depends: libavcodec57 (>= 7:3.0) | libavcodec-extra57 (>= 7:3.0), libavdevice57 
(>= 7:3.0), libavfilter6 (>= 7:3.0), libavformat57 (>= 7:3.0), libavresample3 
(>= 7:3.0), libavutil55 (>= 7:3.0), libc6 (>= 2.14), libpostproc54 (>= 7:3.0), 
libsdl1.2debian (>= 1.2.11), libswresample2 (>= 7:3.0), libswscale4 (>= 7:3.0), 
libvdpau1 (>= 0.2), libx11-6
Suggests: ffmpeg-doc
Breaks: libav-tools (<< 6:12~~), qt-faststart (<< 7:2.7.1-3~)
Conffiles:
 /etc/ffserver.conf 81b94256d412c37f0f81214b3737ac53
Description: Tools for transcoding, streaming and playing of multimedia files
 FFmpeg is the leading multimedia framework, able to decode, encode, transcode,
 mux, demux, stream, filter and play pretty much anything that humans and
 machines have created. It supports the most obscure ancient formats up to the
 cutting edge.
 .
 This package contains:
  * ffmpeg: a command line tool to convert multimedia files between formats
  * ffserver: a multimedia streaming server for live broadcasts
  * ffplay: a simple media player based on SDL and the FFmpeg libraries
  * ffprobe: a simple multimedia stream analyzer
  * qt-faststart: a utility to rearrange Quicktime files
Homepage: https://ffmpeg.org/

I don't know any of the ardour/harvid internals, but it seems it's harvid who
manages the videos. If not, please move this bug to ardour.

Thanks.

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

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

Versions of packages harvid depends on:
ii  libavcodec57 7:3.1.3-2+b1
ii  libavformat577:3.1.3-2+b1
ii  libavutil55  7:3.1.3-2+b1
ii  libc62.24-3
ii  libjpeg62-turbo  1:1.5.0-1
ii  libpng16-16  1.6.25-1
ii  libswscale4  7:3.1.3-2+b1

harvid recommends no packages.

harvid suggests no packages.

-- no debconf information

Bug#840836: ardour: please point to harvid

[Arturo Borrero Gonzalez]

Package: ardour
Version: 1:5.3~dfsg-1
Severity: normal

Dear team,

thanks for your work with the ardour package, it's really appreciated.

Today it was my first experience with ardour in debian.

I installed it in order to do some modifications to the audio track of a video.

While trying to import the video file, ardour seems to expect harvid running in
the background. However:

 % dpkg -s ardour | grep harvid
 [ no output ]

Please, would you point to harvid in Suggest or even in Recommends?

Thanks, best regards.

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

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

Versions of packages ardour depends on:
ii  ardour-data   1:5.3~dfsg-1
ii  jackd 5
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libatkmm-1.6-1v5  2.24.2-2
ii  libaubio4 0.4.1-2.2
ii  libbluetooth3 5.36-1+b3
ii  libc6 2.24-3
ii  libcairo2 1.14.6-1+b1
ii  libcairomm-1.0-1v51.12.0-1+b1
ii  libcurl3-gnutls   7.50.1-1
ii  libcwiid1 0.6.00+svn201-3.2
ii  libfftw3-single3  3.3.5-1
ii  libflac8  1.3.1-4
ii  libfluidsynth11.1.6-3+b1
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-11
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.0-2
ii  libglibmm-2.4-1v5 2.50.0-1
ii  libgtk2.0-0   2.24.31-1
ii  libgtkmm-2.4-1v5  1:2.24.5-1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-2+b1
ii  liblilv-0-0   0.24.0~dfsg0-1
ii  liblo70.28-5
ii  liblrdf0  0.4.0-7
ii  libltc11  1.2.0-1
ii  libogg0   1.3.2-1
ii  libpango-1.0-01.40.3-2
ii  libpangocairo-1.0-0   1.40.3-2
ii  libpangoft2-1.0-0 1.40.3-2
ii  libpangomm-1.4-1v52.40.1-3
ii  librubberband21.8.1-6+b1
ii  libsamplerate00.1.8-8
ii  libserd-0-0   0.24.0~dfsg0-1
ii  libsigc++-2.0-0v5 2.10.0-1
ii  libsndfile1   1.0.25-10
ii  libsord-0-0   0.16.0~dfsg0-1
ii  libsratom-0-0 0.6.0~dfsg0-1
ii  libstdc++66.1.1-11
ii  libsuil-0-0   0.8.4~dfsg0-1
ii  libtag1v5 1.11+dfsg.1-0.2
ii  libvamp-hostsdk3v52.6~repack0-2
ii  libvamp-sdk2v52.6~repack0-2
ii  libx11-6  2:1.6.3-1
ii  libxml2   2.9.4+dfsg1-2

Versions of packages ardour recommends:
ii  firefox-esr [www-browser]   45.3.0esr-1
ii  google-chrome-stable [www-browser]  54.0.2840.59-1
ii  iceweasel   45.4.0esr-2
ii  w3m [www-browser]   0.5.3-29

ardour suggests no packages.

-- no debconf information

Bug#840837: sendmail: GreetPause:localhost in access file has unexpected consequences

[Michael Grant]

Package: sendmail
Version: 8.15.2-6
Severity: normal

Dear Maintainer,

If you put lines like this in the access file:

GreetPause:localhost 0

This allows spammers to by-pass the greet pause by simply setting
their reverse dns (PTR record) to 'localhost'.  When this happens, I
see lines like this in the log file:

Oct  7 03:53:18 example sm-mta[9080]: NOQUEUE: connect from localhost [1.2.3.4] 
(may be forged)

and greetpause gets bypassed.

Simply by changing the line to use an ip address:

GreetPause:127.0.0.1 0

causes the sendmail to properly allow only localhost (127.0.0.1) to
bypass the greetpause.

In other words, the access file did not do a dns lookup on 'localhost'
in the access file before checking for a match.

Secondly, and I think greetpause matched on the forged name rather
than the real ip address from the network connection.

-- Package-specific info:
Output of /usr/share/bug/sendmail/script:

ls -alR /etc/mail:
/etc/mail:
total 1060
drwxr-sr-x   8 smmta smmsp  4096 Oct 14 19:59 .
drwxr-xr-x 145 root  root  12288 Oct 15 07:27 ..
-rwxr-xr--   1 root  smmsp 12681 Sep 24 04:27 Makefile
-rw-r--r--   1 root  smmsp 59488 Oct 14 19:59 access
-rw-r-   1 smmta smmsp 86016 Oct 14 19:59 access.db
-rw-r--r--   1 root  smmsp 59422 Oct 10 18:00 access.old
-rw-r--r--   1 smmta smmsp   281 Feb 11  2013 address.resolve
-rw-r--r--   1 smmta smmsp 17989 Oct  9 16:45 aliases
-rw-r--r--   1 smmta smmsp 40960 Oct  9 16:45 aliases.db
-rw-r--r--   1 root  smmsp 17877 Oct  9 16:45 aliases.old
drwxr-sr--   2 smmta smmsp  4096 Mar  4  2016 certs
-rw-r--r--   1 smmta smmsp 16675 Mar 12  2014 charm.networkguild.org.mc
-rw-r--r--   1 root  smmsp  3739 Sep 24 04:27 databases
-rw-r-   1 smmta smmsp56 Mar 22  2015 default-auth-info
-rw-r--r--   1 root  smmsp   235 Oct  9 16:45 genericstable
-rw-r-   1 root  smmsp 12288 Oct  9 16:45 genericstable.db
-rw-r--r--   1 root  smmsp   235 Oct  9 16:45 genericstable.old
-rw-r--r--   1 smmta smmsp  5659 May 10  2015 helpfile
-rw-r--r--   1 smmta smmsp  1419 Oct  9 16:45 local-host-names
-rw-r--r--   1 root  smmsp  1419 Oct  9 16:45 local-host-names.old
drwxr-sr-x   2 smmta smmsp  4096 Oct 15 07:24 m4
-rw-r--r--   1 smmta smmsp   300 Oct  9 16:45 mailertable
-rw-r-   1 root  smmsp 12288 Oct  9 16:45 mailertable.db
-rw-r--r--   1 root  smmsp   300 Oct  9 16:45 mailertable.old
drwxr-xr-x   2 smmta smmsp  4096 Sep 23 05:42 peers
-rw-r--r--   1 root  smmsp 0 Dec 25  2015 relay-domains
drwxr-xr-x   2 smmta smmsp  4096 May 20  2015 sasl
-rw-r--r--   1 root  smmsp 84657 Sep 24 04:27 sendmail.cf
-rw-r--r--   1 root  smmsp 84429 Jan 29  2016 sendmail.cf.backup-BD
-rw-r--r--   1 root  root  84748 Sep 23 05:43 sendmail.cf.old
-rw-r--r--   1 root  root  12236 Sep 23 05:43 sendmail.conf
-rw-r--r--   1 root  smmsp 10742 Sep 24 04:27 sendmail.mc
-rw-r--r--   1 root  smmsp 11061 Mar  4  2016 sendmail.mc-
-rw-r--r--   1 root  smmsp 10704 Jan 29  2016 sendmail.mc.backup-BD
-rw-r--r--   1 smmta smmsp   149 Feb 11  2013 service.switch
-rw-r--r--   1 smmta smmsp   180 Feb 11  2013 service.switch-nodns
drwxr-sr-x   2 smmta smmsp  4096 May 20  2015 smrsh
lrwxrwxrwx   1 root  root 15 Aug 29 17:14 spamassassin -> ../spamassassin
-rw-r--r--   1 root  smmsp 44696 Sep 23 05:43 submit.cf
-rw-r--r--   1 root  root  44695 Sep 23 05:43 submit.cf.old
-rw-r--r--   1 root  smmsp  2453 Sep 23 05:43 submit.mc
drwxr-xr-x   2 smmta smmsp  4096 Feb 24  2016 tls
-rw-r--r--   1 smmta smmsp 6 Jan 10  2015 trusted-users
-rw-r--r--   1 smmta smmsp 37416 Oct  9 16:45 virtusertable
-rw-r-   1 root  smmsp 86016 Oct  9 16:45 virtusertable.db
-rw-r--r--   1 root  smmsp 37256 Oct  9 16:45 virtusertable.old

/etc/mail/certs:
total 0
d? ? ? ? ?? .
d? ? ? ? ?? ..
l? ? ? ? ?? 38d751eb.0
l? ? ? ? ?? 6e803117.0
-? ? ? ? ?? dh_2048.pem
-? ? ? ? ?? dh_4096.pem
l? ? ? ? ?? f131b364.0
-? ? ? ? ?? geotrust-ca.crt
-? ? ? ? ?? networkguild.org.crt
-? ? ? ? ?? networkguild.org.csr
-? ? ? ? ?? networkguild.org.key
-? ? ? ? ?? strange.networkguild.org.crt
-? ? ? ? ?? strange.networkguild.org.csr
-? ? ? ? ?? strange.networkguild.org.key
-? ? ? ? ?? sub.class1.server.ca.pem

/etc/mail/m4:
total 12
drwxr-sr-x 2 smmta smmsp 4096 Oct 15 07:24 .
drwxr-sr-x 8 smmta smmsp 4096 Oct 14 19:59 ..
-rw-r--r-- 1 root  root   789 Jul  3  2014 clamav-milter.m4
-rw-r- 1 root  smmsp0 Mar 12  2014 dialup.m4
-rw-r- 1 root  smmsp0 Mar 12  2014 provider.m4

/etc/mail/peers:
total 12
drwxr-xr-x 2 smmta smmsp 4096 Sep 23 05:42 .
drwxr-sr-x 8 smmta smmsp 4096 Oct 14 19:59 ..
-rw-r--r-- 1 root  root   328 Feb 11  2013 provider

/etc/mail/sasl:
total 16
drwxr-xr-x 2 smmta smmsp 4096 May 20  2015 .
drwxr-sr-x 8 smmta smmsp 

Bug#840768: beignet-dev: arch-dependent files in "Multi-Arch: same" package

[Jakub Wilk]

* Rebecca N. Palmer , 2016-10-14, 20:13:

-   ikiwiki --verbose --no-usedirs --underlaydir docs --plugin map 
--rebuild docs docs_build
+   ikiwiki --verbose --no-usedirs --underlaydir docs --plugin map --rebuild 
--timeformat "`dpkg-parsechangelog -SDate`" docs docs_build


Yes, this fixes the bug.

--
Jakub Wilk

Bug#840836: ardour: please point to harvid

[Arturo Borrero Gonzalez]

On 15 October 2016 at 14:34, Arturo Borrero Gonzalez  wrote:
>
> Please, would you point to harvid in Suggest or even in Recommends?
>

Perhaps same applies to 'xjadeo'.

Bug#840836: ardour: please point to harvid

[Arturo Borrero Gonzalez]

For the record, this is the ardour log console:

[WARNING]: The external video server 'harvid' can not be found.
The tool is included with the Ardour releases from ardour.org,
alternatively you can download it from http://x42.github.com/harvid/
or acquire it from your distribution.

see also http://manual.ardour.org/video-timeline/setup/
[WARNING]: ffmpeg installation was not found on this system.
Ardour requires ffmpeg and ffprobe from ffmpeg.org - version 1.1 or newer.
Video import and export is not possible until you install tools.

The tools are included with the Ardour releases from ardour.org and
also available with the video-server at http://x42.github.com/harvid/

Important: the files need to be installed in $PATH and named
ffmpeg_harvid and ffprobe_harvid.
If you already have a suitable ffmpeg installation on your system, we
recommend creating symbolic links from ffmpeg to ffmpeg_harvid and
from ffprobe to ffprobe_harvid.

see also http://manual.ardour.org/video-timeline/setup/

Bug#836821: Revised patch for python3-protobuf

[lumin]

Hi,

I'm eager to build my package on the top of python3-protbuf.
My d-science package python3-caffe* had been waiting in
experimental for a long time, and python3-protobuf is the
last blocker which stopped my package from entering unstable.

I updated Thomas Viehmann's patch (Thank you!) with minor
revision, and it works for me -- I have successfully built
python3-protobuf on sid, and the resulting python3-protobuf
package works well with my package python3-caffe*. But
I didn't try e.g. a debomatic-amd64 build.

Please update the protobuf package with python3 support.
If you are too busy to do that, I'll willing to do an NMU.
Thank you! :-)commit dae90116fff7a100538eece963075d36304f14fa
Author: Zhou Mo 
Date:   Sat Oct 15 12:42:22 2016 +

python3-protobuf

diff --git a/debian/changelog b/debian/changelog
index 26f245d..1b6a0ff 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+protobuf (3.0.0-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch to enable python 3. Closes: #836821
+
+ -- Thomas Viehmann   Sat, 10 Sep 2016 00:00:00 +
+
 protobuf (3.0.0-7) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/clean b/debian/clean
index f723754..a16e6fe 100644
--- a/debian/clean
+++ b/debian/clean
@@ -1 +1,3 @@
 protoc.1
+debian/autoreconf.after
+debian/autoreconf.before
diff --git a/debian/control b/debian/control
index 7e73b8c..3c08992 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,10 @@ Build-Depends:
  , dh-python
  , python-all (>= 2.7)
  , libpython-all-dev (>= 2.7)
+ , python3-all (>= 3.3)
+ , libpython3-all-dev (>= 3.3)
  , python-setuptools
+ , python3-setuptools
  , python-google-apputils
 # Manpage generator
  , xmlto
@@ -181,6 +184,27 @@ Description: Python bindings for protocol buffers
  definition to Python classes, and then the modules in this package will allow
  you to use those classes in your programs.
 
+Package: python3-protobuf
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Description: Python 3 bindings for protocol buffers
+ Protocol buffers are a flexible, efficient, automated mechanism for
+ serializing structured data - similar to XML, but smaller, faster, and
+ simpler. You define how you want your data to be structured once, then you can
+ use special generated source code to easily write and read your structured
+ data to and from a variety of data streams and using a variety of languages.
+ You can even update your data structure without breaking deployed programs
+ that are compiled against the "old" format.
+ .
+ Google uses Protocol Buffers for almost all of its internal RPC protocols and
+ file formats.
+ .
+ This package contains the Python 3 bindings for the protocol buffers. You will
+ need the protoc tool (in the protobuf-compiler package) to compile your
+ definition to Python classes, and then the modules in this package will allow
+ you to use those classes in your programs.
+
 Package: libprotobuf-java
 Architecture: all
 Depends: ${misc:Depends}
diff --git a/debian/python-protobuf3.README.Debian b/debian/python-protobuf3.README.Debian
new file mode 100644
index 000..61d0c1b
--- /dev/null
+++ b/debian/python-protobuf3.README.Debian
@@ -0,0 +1,11 @@
+C++ backend
+===
+
+As of protobuf 2.6.0, a new C++ backend for the Python protobuf bindings is
+available, which is faster than the default pure Python implementation. It can
+be activated by setting the following environment variables:
+
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION_VERSION=2
+
+ -- Robert Edmonds   Thu, 28 Aug 2014 21:10:30 -0700
diff --git a/debian/rules b/debian/rules
index 8445efb..ab3e62a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with autoreconf,python2 --parallel
+	dh $@ --with autoreconf,python2,python3 --parallel
 
 override_dh_auto_build-arch:
 ## Chicken<->Egg problem: protobuf requires self-generated .pb.go files to
@@ -14,8 +14,10 @@ override_dh_auto_build-arch:
 	# Generate the manpage.
 	xmlto man debian/protoc.xml
 
-	# Python build.
+	# Python and Python3 build.
+	cp -rv python python3
 	cd python && python setup.py build --cpp_implementation
+	cd python3 && python3 setup.py build --cpp_implementation
 
 override_dh_auto_build-indep:
 	dh_auto_build --indep
@@ -45,6 +47,10 @@ ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 	cd python && for python in $(shell pyversions -r); do \
 		$$python setup.py test --cpp_implementation; \
 	done
+# Python3 test.
+	cd python3 && for python in $(shell py3versions -r); do \
+		$$python setup.py test --cpp_implementation; \
+	done
 endif
 
 override_dh_auto_test-indep:
@@ -58,6 +64,8 @@ override_dh_auto_clean-arch:
 		$$python setup.py clean --all; \
 	done
 	rm -rf python/protobuf.egg-info
+	# Python3 clean.
+	-rm -rf python3
 
 override_dh_auto_clean-indep:
 	dh_auto_clean --indep
@@ -78,6 +86,14 @@ override_dh_

Bug#840725: libhmsbeagle: FTBFS and bd-uninstallable almost everywhere

[Emilio Pozuelo Monfort]

Control: reopen -1
Control: found -1 2.1.2+20160831-1

Hi,

On 14/10/16 10:21, Andreas Tille wrote:
> Hi Emilio,
> 
> this is a known issue which would be fixed if khronos-opencl-clhpp would
> be accepted by ftpmaster in new queue.  I've given a hint to frpmaster
> about this hoping that this can be solved quickly but unfortunately with
> no success so far. :-(

Not sure how that was supposed to help, but the new version still fails to build
on i386, and is still bd-uninst because of the missing libpoclu-dev everywhere
else, see

https://buildd.debian.org/status/package.php?p=libhmsbeagle

Cheers,
Emilio

Bug#837281: manila-ui: FTBFS: compressor.exceptions.OfflineGenerationError: No template loaders defined. You must set TEMPLATE_LOADERS in your settings or set 'loaders' in your TEMPLATES dictionary.

[Andreas Beckmann]

Followup-For: Bug #837281

Hi,

attached is a piuparts log from python-manila-ui_2.5.1-0 in stretch
showing the same problem. This pulled in

python-django all 1:1.10.1-1
python-django-horizon all 3:9.0.1-2
openstack-dashboard all 3:9.0.1-2

python-django-horizon and openstack-dashboard have 3:10.0.0-1 in
unstable, so maybe the dependencies are not yet strict enough to pull in
all the required new package versions?

Andreas


python-manila-ui_2.5.1-0.log.gz
Description: application/gzip

Bug#239816: bug#16134: libparted Atari partition table support

[John Paul Adrian Glaubitz]

Hi!

I just stumbled into this bug again since I wanted to use parted today to
create a disk image that would be recognized by ARAnyM with a kernel with
just Atari partition support.

I pulled the old patch from Stephen's git repository, applied it to the
current git version of parted which surprisingly still worked, albeit
the patches applied with some fuzz.

However, the code did not build anymore, so I fixed all compiler errors
and warnings and was now able to run parted with the patch merged.

Creating a partition table with "mklabel atari" worked, but now libparted
crashed when running "mkpart". After refactoring the Atari code to make
use of pt-common.h and pt-tools.h, this problem was fixed, too.

I then tried the image on Aranym but to my disappointment, the kernel did
not recognize the partition table, so there is still something wrong with
the patch as-is.

I'm attaching my current patch for parted. Maybe someone else has an idea
what I might be missing here to get the kernel recognize the partition
table created with the patched version of parted.

Once we have sorted the remaining issues out, I will take care of adding
the necessary tests and get the changes merged upstream.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From c965b4144784341003d9b1000df96da1a1ac1aff Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz 
Date: Sat, 15 Oct 2016 14:52:17 +0200
Subject: [PATCH] Add support for Atari partition labels

---
 libparted/labels/Makefile.am |1 +
 libparted/labels/atari.c | 1969 ++
 libparted/libparted.c|4 +
 po/POTFILES.in   |1 +
 4 files changed, 1975 insertions(+)
 create mode 100644 libparted/labels/atari.c

diff --git a/libparted/labels/Makefile.am b/libparted/labels/Makefile.am
index c996f81..3327c8c 100644
--- a/libparted/labels/Makefile.am
+++ b/libparted/labels/Makefile.am
@@ -19,6 +19,7 @@ noinst_LTLIBRARIES=	liblabels.la
 liblabels_la_SOURCES = \
   $(S390_SRCS)	\
   aix.c		\
+  atari.c	\
   bsd.c		\
   dos.c		\
   dvh.c		\
diff --git a/libparted/labels/atari.c b/libparted/labels/atari.c
new file mode 100644
index 000..8f85ccd
--- /dev/null
+++ b/libparted/labels/atari.c
@@ -0,0 +1,1969 @@
+/* -*- Mode: c; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 8 -*-
+
+libparted - a library for manipulating disk partitions
+disk_amiga.c - libparted module to manipulate amiga RDB partition tables.
+Copyright (C) 2000-2001, 2004, 2007-2014 Free Software Foundation, Inc.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program.  If not, see .
+
+Contributor:  Guillaume Knispel 
+  John Paul Adrian Glaubitz 
+*/
+
+/*
+	Documentation :
+		README file of atari-fdisk
+		atari-fdisk source code
+		Linux atari partitions parser source code
+			( fs/partitions/atari.[ch] )
+*/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pt-tools.h"
+
+#if ENABLE_NLS
+#  include 
+#  define _(String) dgettext (PACKAGE, String)
+#else
+#  define _(String) (String)
+#endif /* ENABLE_NLS */
+
+
+/** Atari data and structure stuff **/
+
+#define BOOTABLE_CKSUM		0x1234
+#define NONBOOT_CKSUM		0x4321
+
+#define GEM_MAX			((32*1024*1024)/PED_SECTOR_SIZE_DEFAULT)
+
+#define PART_FLAG_USED		0x01
+#define PART_FLAG_BOOT_GEM	0x80	/* GEMDOS	   */
+#define PART_FLAG_BOOT_ASV	0x40	/* Atari System V  */
+#define PART_FLAG_BOOT_BSD	0x20	/* Net(?)BSD	   */
+#define PART_FLAG_BOOT_LNX	0x10	/* Linux	   */
+#define PART_FLAG_BOOT_UNK	0x08	/* unknown / other */
+
+#define N_AHDI			4
+#define N_ICD			8
+
+#define MAXIMUM_PARTS		64
+
+/* what we put instead of id, start and size in empty */
+/* partition tables, to be able to detect it */
+#define SIGNATURE_EMPTY_TABLE	"PARTEDATARI"
+#define SIGNATURE_EMPTY_SIZE	11
+
+/* to be compared to the last two bytes of 1st sector (Big Endian) */
+static const uint16_t atr_forbidden_sign[] = {
+	0x55AA,
+	0
+};
+
+static const char *atr_known_icd_pid[] = {
+	"BGM", "GEM", "LNX", "SWP", "RAW", NULL
+};
+
+/* static const char *atr_known_pid[] = { */
+/* 	"BGM", "GEM", "LNX", "MAC

Bug#837917: Solution found

[Maximiliano Curia]

Control: tag -1 + upstream
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=368786

¡Hola Werner!

El 2016-10-15 a las 14:04 +0200, Werner Mahr escribió:
as I ran into the same problem, I first searched for the rar-mimetype in 
systemsettings.


rar is known there as application/vnd.rar 
but in plugins/clirarplugin/kerfuffle_clirar.json everything refers to 
application/x-rar



After adjusting this setting and recompiling, everything worked like always.



I just don't know, if the mimetypes or ark uses an older setting for this.


Oh, this seems to be fixed in 16.08.2, which will probably land in sid in a 
couple of days.


Happy hacking,
--
"People get lost in thought because it is unfamiliar territory."
-- Fix's Principle
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#839931: freeradius-config: fails to upgrade from 'sid' - trying to overwrite /etc/freeradius/clients.conf

[Andreas Beckmann]

Followup-For: Bug #839931
Control: found -1 3.0.12+dfsg-1

Hi,

there are still file overwrite problems in the latest version:

  Preparing to unpack .../07-freeradius_3.0.12+dfsg-1_amd64.deb ...
  Unpacking freeradius (3.0.12+dfsg-1) over (2.2.8+dfsg-0.1+b3) ...
  dpkg: warning: unable to delete old directory 
'/etc/freeradius/sites-enabled': Directory not empty
  dpkg: warning: unable to delete old directory 
'/etc/freeradius/sites-available': Directory not empty
  dpkg: warning: unable to delete old directory '/etc/freeradius/modules': 
Directory not empty
  dpkg: warning: unable to delete old directory '/etc/freeradius/certs': 
Directory not empty
  dpkg: warning: unable to delete old directory '/etc/freeradius': Directory 
not empty
  Selecting previously unselected package freeradius-config.
  Preparing to unpack .../08-freeradius-config_3.0.12+dfsg-1_amd64.deb ...
  Unpacking freeradius-config (3.0.12+dfsg-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-5B7fDA/08-freeradius-config_3.0.12+dfsg-1_amd64.deb 
(--unpack):
   trying to overwrite '/etc/freeradius/hints', which is also in package 
freeradius 3.0.12+dfsg-1


Andreas

Bug#840424: Could you fix the error that is found by verilog-mode testing on Debian?

[Kiwamu Okabe]

On Sat, Oct 15, 2016 at 7:44 PM, Wilson Snyder  wrote:
> Makes sense.  I suspect the eval is turned off as
> root/fakeroot for security, however this verilog-mode test
> depends on that eval feature, so obviously the test will
> fail.

I understand detail of that, now. At far future, you'll try to support
running the test on root user? Or not?

Best regards,
-- 
Kiwamu Okabe at METASEPI DESIGN

Bug#840838: plasma-desktop: There are not jumplist for applications and firefox

[Christophe Leloup]

Package: plasma-desktop
Version: 4:5.8.0-1
Severity: minor

Dear Maintainer,

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

   * What led up to the situation?
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   right-click
   * What outcome did you expect instead?

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

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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.8.0-1
ii  kactivitymanagerd5.8.0-1
ii  kde-cli-tools4:5.8.0-1
ii  kded55.26.0-1
ii  kio  5.26.0-1
ii  libc62.24-3
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.7
ii  libgcc1  1:6.2.0-6
ii  libkf5activities55.26.0-1
ii  libkf5activitiesstats1   5.26.0-1
ii  libkf5archive5   5.26.0-1
ii  libkf5auth5  5.26.0-1
ii  libkf5baloo5 5.26.0-1
ii  libkf5bookmarks5 5.26.0-1
ii  libkf5codecs55.26.0-1
ii  libkf5completion55.26.0-1
ii  libkf5configcore55.26.0-1
ii  libkf5configgui5 5.26.0-1
ii  libkf5configwidgets5 5.26.0-1
ii  libkf5coreaddons55.26.0-3
ii  libkf5dbusaddons55.26.0-1
ii  libkf5emoticons-bin  5.26.0-1
ii  libkf5emoticons5 5.26.0-1
ii  libkf5globalaccel5   5.26.0-1
ii  libkf5guiaddons5 5.26.0-1
ii  libkf5i18n5  5.26.0-1
ii  libkf5iconthemes55.26.0-1
ii  libkf5itemmodels55.26.0-1
ii  libkf5itemviews5 5.26.0-1
ii  libkf5jobwidgets55.26.0-1
ii  libkf5kcmutils5  5.26.0-1
ii  libkf5kdelibs4support5   5.26.0-1
ii  libkf5kiocore5   5.26.0-1
ii  libkf5kiofilewidgets55.26.0-1
ii  libkf5kiowidgets55.26.0-1
ii  libkf5newstuff5  5.26.0-1
ii  libkf5notifications5 5.26.0-2
ii  libkf5notifyconfig5  5.26.0-1
ii  libkf5parts5 5.26.0-1
ii  libkf5people55.26.0-1
ii  libkf5peoplewidgets5 5.26.0-1
ii  libkf5plasma55.26.0-2
ii  libkf5plasmaquick5   5.26.0-2
ii  libkf5quickaddons5   5.26.0-1
ii  libkf5runner55.26.0-1
ii  libkf5service-bin5.26.0-1
ii  libkf5service5   5.26.0-1
ii  libkf5solid5 5.26.0-1
ii  libkf5sonnetui5  5.26.0-1
ii  libkf5wallet-bin 5.26.0-1
ii  libkf5wallet55.26.0-1
ii  libkf5widgetsaddons5 5.26.0-1
ii  libkf5windowsystem5  5.26.0-1
ii  libkf5xmlgui55.26.0-1
ii  libkfontinst54:5.8.0-1
ii  libkfontinstui5  4:5.8.0-1
ii  libkworkspace5-5 4:5.8.0-1
ii  libpackagekitqt5-0   0.9.6-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libpulse-mainloop-glib0  9.0-4
ii  libpulse09.0-4
ii  libqt5concurrent55.6.1+dfsg-3+b1
ii  libqt5core5a 5.6.1+dfsg-3+b1
ii  libqt5dbus5  5.6.1+dfsg-3+b1
ii  libqt5gui5   5.6.1+dfsg-3+b1
ii  libqt5network5   5.6.1+dfsg-3+b1
ii  libqt5printsupport5  5.6.1+dfsg-3+b1
ii  libqt5qml5   5.6.1-11
ii  libqt5quick5 5.6.1-11
ii  libqt5quickwidgets5  5.6.1-11
ii  libqt5sql5   5.6.1+dfsg-3+b1
ii  libqt5svg5   5.6.1-2
ii  libqt5widgets5   5.6.1+dfsg-3+b1
ii  libqt5x11extras5 5.6.1-2
ii  libqt5xml5   5.6.1+dfsg-3+b1
ii  libscim8v5  

Bug#840839: youtube-dl: the is a new version.

[Christophe Leloup]

Package: youtube-dl
Version: 2016.06.25-2
Severity: wishlist

Dear Maintainer,

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

there is a new version.

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


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

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

Versions of packages youtube-dl depends on:
ii  python-pkg-resources  28.0.0-1
pn  python:any

Versions of packages youtube-dl recommends:
ii  ca-certificates  20160104
ii  ffmpeg   7:3.1.4-1
ii  mpv  0.20.0-1+b1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-1
ii  wget 1.18-4

youtube-dl suggests no packages.

-- no debconf information

Bug#840828: [Pkg-tigervnc-devel] Bug#840828: tigervnc-viewer: leaves alternatives after purge: /usr/bin/{, x}vncviewer

[Ola Lundqvist]

Hi Andreas

Thanks for the report.

/ Ola

Sent from a phone

Den 15 okt 2016 13:33 skrev "Andreas Beckmann" :

> Package: tigervnc-viewer
> Version: 1.6.0+dfsg-2
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8:
>
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-
> removedetails
>
> The leftover files are actually alternatives that were installed by the
> package but have not been properly removed.
>
> While there is ongoing discussion how to remove alternatives correctly
> (see https://bugs.debian.org/71621 for details) the following strategy
> should work for regular cases:
> * 'postinst configure' always installs the alternative
> * 'prerm remove' removes the alternative
> * 'postrm remove' and 'postrm disappear' remove the alternative
> In all other cases a maintainer script is invoked (e.g. upgrade,
> deconfigure) the alternatives are not modified to preserve user
> configuration.
> Removing the alternative in 'prerm remove' avoids having a dangling link
> once the actual file gets removed, but 'prerm remove' is not called in
> all cases (e.g. unpacked but not configured packages or disappearing
> packages) so the postrm must remove the alternative again
> (update-alternatives gracefully handles removal of non-existing
> alternatives).
>
> Note that the arguments for adding and removing alternatives differ, for
> removal it's 'update-alternatives --remove  '.
>
> Filing this as important as having a piuparts clean archive is a release
> goal since lenny.
>
> >From the attached log (scroll to the bottom...):
>
> 0m27.9s INFO: Warning: Package purging left files on system:
>   /etc/alternatives/vncviewer -> /usr/bin/xtigervncviewernot owned
>   /etc/alternatives/vncviewer.1.gz -> /usr/share/man/man1/xtigervncviewer.1.gz
>  not owned
>   /etc/alternatives/xvncviewer -> /usr/bin/xtigervncviewer   not owned
>   /etc/alternatives/xvncviewer.1.gz -> 
> /usr/share/man/man1/xtigervncviewer.1.gz
> not owned
>   /usr/bin/vncviewer -> /etc/alternatives/vncviewer  not owned
>   /usr/bin/xvncviewer -> /etc/alternatives/xvncviewernot owned
>   /usr/share/man/man1/vncviewer.1.gz -> /etc/alternatives/vncviewer.1.gz
>not owned
>   /usr/share/man/man1/xvncviewer.1.gz -> /etc/alternatives/xvncviewer.1.gz
>  not owned
>
>
> cheers,
>
> Andreas
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>

Bug#840840: pocl: Does not build on several architectures

[Andreas Tille]

Source: pocl
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

the pocl source does not build on several architectures where it has built
before.  The problem seem to be failed tests.  Please see:

https://buildd.debian.org/status/package.php?p=pocl

Kind regards and thanks for maintaining pocl

 Andreas.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/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)

Bug#840841: digikam: fails to upgrade from jessie to stretch: gets removed, not upgraded

[Andreas Beckmann]

Package: digikam
Version: 4:5.2.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'stretch' fails.

>From the attached log (scroll to the bottom...):

[...]
# distupgrade from jessie to stretch
3m14.4s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmp_SRqAA', 
'apt-get', '-yf', 'dist-upgrade']
5m43.2s DUMP: 
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following packages were automatically installed and are no longer 
required:
[...]
  Use 'apt-get autoremove' to remove them.
  The following packages will be REMOVED:
digikam digikam-private-libs libclucene-core1 libebml4 libgpgme++2
libmarblewidget19 libmatroska6 libopencv-calib3d2.4 libopencv-contrib2.4
libopencv-core2.4 libopencv-features2d2.4 libopencv-flann2.4
libopencv-highgui2.4 libopencv-imgproc2.4 libopencv-ml2.4
libopencv-objdetect2.4 libopencv-video2.4 libproxy1 libstreamanalyzer0
libtag1-vanilla libtag1c2a perl-modules vlc-plugin-pulse
  The following NEW packages will be installed:
[...]

# ok, lets try to install it in stretch
5m45.0s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmp_SRqAA', 
'apt-get', '-y', 'install', 'digikam']
5m45.6s DUMP: 
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   digikam : Depends: digikam-private-libs (= 4:5.2.0-1) but it is not going to 
be installed
  E: Unable to correct problems, you have held broken packages.
5m45.6s ERROR: Command failed (status=100): ['chroot', 
'/tmp/piupartss/tmp_SRqAA', 'apt-get', '-y', 'install', 'digikam']
  

cheers,

Andreas


digikam_4:5.2.0-1.log.gz
Description: application/gzip

Bug#840842: udevil: Hard to read EXAMPLES section in the udevil manpage due to formatting

[Hans Joachim Desserud]

Package: udevil
Version: 0.4.4-1
Severity: normal

Dear Maintainer,

The udevil manpage contains an EXAMPLES section which demonstrates
various ways to use the program. However, it seems to formatted into
a long, continuous block, making it rather hard to read. See for
instance [1]. Would probably be easier if each command/example were
on separate lines.  :)

(This was originally reported in Ubuntu as [2])

[1] http://manpages.ubuntu.com/manpages/xenial/man1/udevil.1.html
[2] https://bugs.launchpad.net/ubuntu/+source/udevil/+bug/1614419

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
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 udevil depends on:
ii  libc6 2.24-3
ii  libglib2.0-0  2.50.1-1
ii  libudev1  231-9

Versions of packages udevil recommends:
ii  pmount   0.9.23-3+b1
ii  udisks2  2.1.7-2
ii  zenity   3.22.0-1

Versions of packages udevil suggests:
pn  cifs-utils  
pn  curlftpfs   
ii  eject   2.1.5+deb1+cvs20081104-13.1
pn  sshfs   

-- no debconf information

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#840843: dia: leaves alternatives after purge: /etc/alternatives/dia

[Andreas Beckmann]

Package: dia
Version: 0.97.3+git20160930-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

While there is ongoing discussion how to remove alternatives correctly
(see https://bugs.debian.org/71621 for details) the following strategy
should work for regular cases:
* 'postinst configure' always installs the alternative
* 'prerm remove' removes the alternative
* 'postrm remove' and 'postrm disappear' remove the alternative
In all other cases a maintainer script is invoked (e.g. upgrade,
deconfigure) the alternatives are not modified to preserve user
configuration.
Removing the alternative in 'prerm remove' avoids having a dangling link
once the actual file gets removed, but 'prerm remove' is not called in
all cases (e.g. unpacked but not configured packages or disappearing
packages) so the postrm must remove the alternative again
(update-alternatives gracefully handles removal of non-existing
alternatives).

Note that the arguments for adding and removing alternatives differ, for
removal it's 'update-alternatives --remove  '.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

2m19.7s INFO: Warning: Package purging left files on system:
  /etc/alternatives/dia -> /usr/bin/dia-normal-integratednot owned

This was observed on a jessie->stretch upgrade.


cheers,

Andreas


dia_0.97.3+git20160930-1.log.gz
Description: application/gzip

Bug#840844: kde-standard: Please add kdeconnect to kde-standard

[Diederik de Haas]

Package: kde-standard
Version: 5:91
Severity: wishlist

The kdeconnect package isn't part of any kde meta-package and I think it
should as it really nicely integrates my Android devices with my KDE
desktop and I therefor have installed it on my PC, laptop and all my
Android devices. As a matter of fact when I install a new device it is
one of the very first packages/apps I do install on that device.

On top of that, it is explicitly mentioned in the Plasma 5.8 LTS
announcement [1] and it is also featured in the video on that page.
Thus it is likely that users of KDE in Debian Stretch expect it to be
installed by default.

I would be fine if this bug was reassigned to kde-plasma-desktop, the
metapackage I normally use, or alternatively to kde-full, but I'll leave
that up to the maintainer. Or close it as 'wont-fix', but I had to at
least try to get it into a Debian KDE metapackage ;-)

Cheers,
  Diederik

[1]
https://dot.kde.org/2016/10/04/kde-20-plasma-58-lts-out-now-comprehensive-features


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

Kernel: Linux 4.8.0-rc8-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#840641: ITP: python-lecm -- letsencrypt certificates manager

[Mattia Rizzolo]

On Fri, Oct 14, 2016 at 07:01:54PM +0200, Sebastien Badia wrote:
> Sure, good idea, I just requested to join the letsencrypt team on alioth.d.o
> Thanks! And thanks for the sponsoring!

I saw that somebody added you, great :)
I suggest you also subscribe
https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel and
send sponsorship requests there (instead of mailing me privately).
There is not so much traffic in there, don't worry ;)


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#840845: python-pygraphviz: FTBFS with /bin/sh as bash

[Chris Lamb]

Source: python-pygraphviz
Version: 1.3.1-1
Severity: serious
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Due to the commented-out "set -e; \" line (note the trailing backslash!),
python-pygraphviz FTBFS when /bin/sh is bash.

Minimal patch attached. However, you should probably uncomment the set
-e bit and drop the leading - so that test failures actually cause a
FTBFS otherwise that's another bug IMHO.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index fcb04c5..f0e6a22 100755
--- a/debian/rules
+++ b/debian/rules
@@ -42,7 +42,7 @@ override_dh_installdocs:
 
 override_dh_auto_test:
 ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
-   #set -e; \
+   #set -e;
-for python in $(PYTHON2) $(PYTHON3); do \
echo "-- running tests for "$$python" plain --" ; \
LIB=$$($$python -c "from distutils.command.build import build ; 
from distutils.core import Distribution ; b = build(Distribution()) ; 
b.finalize_options() ; print (b.build_platlib)") ; \

Bug#239816: bug#16134: libparted Atari partition table support

[John Paul Adrian Glaubitz]

On 10/15/2016 03:11 PM, John Paul Adrian Glaubitz wrote:
> I then tried the image on Aranym but to my disappointment, the kernel did
> not recognize the partition table, so there is still something wrong with
> the patch as-is.

Ah, it works after enabling byte-swapping in ARAnyM :).

Alright, will clean this up, add tests and then get it merged!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#840838: plasma-desktop: There are not jumplist for applications and firefox

[Diederik de Haas]

On zaterdag 15 oktober 2016 15:17:13 CEST Christophe Leloup wrote:
>* What was the outcome of this action?
>right-click

Could you expand your description of the problem? And how you expect the 
solution to look like? 
I couldn't tell what the problem is and how the solution should look like and 
I may not be the only one ;-)


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

Bug#840846: tornado-pyvows: accesses the internet during build

[Chris Lamb]

Source: tornado-pyvows
Version: 0.6.1-1
Severity: important
Justification: Policy 4.9
User: la...@debian.org
Usertags: network-access

Dear Maintainer,

Whilst tornado-pyvows builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build.

  00:00:00.00 IP c31868eaee2e.47342 > ns1.ipko.net.domain: 40350+ A? 
requestb.in. (29)
  00:00:00.53 IP c31868eaee2e.47342 > ns1.ipko.net.domain: 56135+ ? 
requestb.in. (29)
  00:00:00.045967 IP ns1.ipko.net.domain > c31868eaee2e.47342: 56135 2/2/4  
2400:cb00:2048:1::681f:56cc,  2400:cb00:2048:1::681f:57cc (227)
  00:00:00.053499 IP ns1.ipko.net.domain > c31868eaee2e.47342: 40350 2/2/4 A 
104.31.86.204, A 104.31.87.204 (203)
  00:00:00.053918 IP c31868eaee2e.52164 > 104.31.86.204.http: Flags [S], seq 
1608517779, win 29200, options [mss 1460,sackOK,TS val 40129078 ecr 
0,nop,wscale 7], length 0
  00:00:00.092213 IP 104.31.86.204.http > c31868eaee2e.52164: Flags [S.], seq 
3321932301, ack 1608517780, win 29200, options [mss 
1460,nop,nop,sackOK,nop,wscale 10], length 0
  00:00:00.092255 IP c31868eaee2e.52164 > 104.31.86.204.http: Flags [.], ack 1, 
win 229, length 0
  00:00:00.092814 IP c31868eaee2e.52164 > 104.31.86.204.http: Flags [P.], seq 
1:160, ack 1, win 229, length 159: HTTP: POST /api/v1/bins HTTP/1.1
  00:00:00.135025 IP 104.31.86.204.http > c31868eaee2e.52164: Flags [.], ack 
160, win 30, length 0
  00:00:00.424905 IP 104.31.86.204.http > c31868eaee2e.52164: Flags [P.], seq 
1:506, ack 160, win 30, length 505: HTTP: HTTP/1.1 200 OK

  [..]

The full build log (including tcpdump output) is attached.


Regards,

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


tornado-pyvows.0.6.1-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#839791: qtcreator: builds with clang support on armel

[Lisandro Damián Nicanor Pérez Meyer]

On miércoles, 5 de octubre de 2016 12:52:08 A. M. ART Emilio Pozuelo Monfort 
wrote:
> Source: qtcreator
> Version: 4.1.0-1
> Severity: serious
> 
> Hi!
> 
> qtcreator builds with LLVM 3.8 on armel, however LLVM 3.8 is not
> available there. (Well, there is an old version still in the archive,
> built from a snapshot from llvm-toolchain-snapshot, which hasn't been
> removed yet, that will happen soon in #839033.
> 
> Note this is blocking testing migration:

Hi! I'm missing some commits in the repo, as soon as they are pushed I'll 
happily fix this.

Soory for the delay!


-- 
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.
  Linus Benedict Torvalds.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#840844: kde-standard: Please add kdeconnect to kde-standard

[Lisandro Damián Nicanor Pérez Meyer]

On sábado, 15 de octubre de 2016 3:44:49 P. M. ART Diederik de Haas wrote:
> Package: kde-standard
> Version: 5:91
> Severity: wishlist
> 
> The kdeconnect package isn't part of any kde meta-package and I think it
> should as it really nicely integrates my Android devices with my KDE
> desktop and I therefor have installed it on my PC, laptop and all my
> Android devices. As a matter of fact when I install a new device it is
> one of the very first packages/apps I do install on that device.
> 
> On top of that, it is explicitly mentioned in the Plasma 5.8 LTS
> announcement [1] and it is also featured in the video on that page.
> Thus it is likely that users of KDE in Debian Stretch expect it to be
> installed by default.

This is correct, but first we would need the last version packaged. For that 
someone needs to put time on fixing the unit tests, I should have updated 
almost all the rest of the packaging.


-- 
No pienses que estoy loco, es sólo una manera de actuar
  De mí - Charly García

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#827335: evince: assertion failed: (wayland_display->cursor_theme_name)

[intrigeri]

Control: reassign -1 apparmor
Control: notfound -1 evince/3.20.0-4
Control: found -1 apparmor/2.10.95-4
Control: affects -1 + evince
Control: retitle -1 evince crashes under Wayland with AppArmor enabled: 
assertion failed: (wayland_display->cursor_theme_name)

Hi,

intrigeri:
> https://code.launchpad.net/~intrigeri/apparmor/wayland/+merge/305422
> I've just poked upstream about it.

… and it was merged. I've cherry-picked it locally in src:apparmor's
Vcs-Bzr and am preparing an upload as we speak.

> If you're in a hurry, patching /etc/apparmor.d/usr.bin.evince as
> proposed on this bug (quoted above) should be a fine
> temporary solution.

… so please don't bother going for that temporary hack.

Cheers,
-- 
intrigeri

Bug#840844: kde-standard: Please add kdeconnect to kde-standard

[Diederik de Haas]

On zaterdag 15 oktober 2016 10:55:26 CEST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> This is correct, but first we would need the last version packaged. For
> that  someone needs to put time on fixing the unit tests, I should have
> updated almost all the rest of the packaging.

Maxy already did \o/
https://packages.qa.debian.org/k/kdeconnect/news/20161014T163805Z.html

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

Bug#695304: libnvidia-ml1: please package libnvidia-ml-dev

[Andreas Beckmann]

Control: reassign -1 nvidia-cuda-dev
Control: tag -1 - moreinfo

On Fri, 07 Dec 2012 08:58:26 +0100 Andreas Beckmann
 wrote:
> On 2012-12-06 21:13, Brice Goglin wrote:
> > The header file nvml.h corresponding to libnvidia-ml1 binary doesn't
> > seem to be packages.
> 
> because it's not part of the driver .run files ...

That header is now shipped as part of the CUDA Toolkit 8.0, so it will
be in the nvidia-cuda-dev package soon.


Andreas

Bug#840825: libtag1-dev: missing header files

[Matteo Cypriani]

Hi James,

Le samedi 15 octobre 2016, 12:02:06 EDT James Cowgill a écrit :
> taglib 1.11+dfsg.1-0.1 and 1.11+dfsg.1-0.2 are missing various include
> files which should be shipped in /usr/include. These are reported by
> dh_install:

Thanks for reporting the problem and sorry for the trouble. I'll be working on 
a new NMU in the next few days.

> This at least breaks kid3 which uses these headers if taglib is new
> enough. Can I also suggest enabling "dh_install --fail-missing" so this
> doesn't happen again :)

Will do, thanks for the suggestion!

Cheers,
  Matteo

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

Bug#827335: evince: assertion failed: (wayland_display->cursor_theme_name)

[Michael Biebl]

Am 15.10.2016 um 15:57 schrieb intrigeri:
> Control: reassign -1 apparmor
> Control: notfound -1 evince/3.20.0-4
> Control: found -1 apparmor/2.10.95-4
> Control: affects -1 + evince
> Control: retitle -1 evince crashes under Wayland with AppArmor enabled: 
> assertion failed: (wayland_display->cursor_theme_name)
> 
> Hi,
> 
> intrigeri:
>> https://code.launchpad.net/~intrigeri/apparmor/wayland/+merge/305422
>> I've just poked upstream about it.
> 
> … and it was merged. I've cherry-picked it locally in src:apparmor's
> Vcs-Bzr and am preparing an upload as we speak.
> 
>> If you're in a hurry, patching /etc/apparmor.d/usr.bin.evince as
>> proposed on this bug (quoted above) should be a fine
>> temporary solution.
> 
> … so please don't bother going for that temporary hack.

Thanks, intrigeri!

This makes me wonder if

  owner /{,var/}run/user/*/dconf/  w,
  owner /{,var/}run/user/*/dconf/user  rw,
and
  owner @{HOME}/.local/share/gvfs-metadata/** l,
  owner /{,var/}run/user/*/gvfs-metadata/** l,

shouldn't be moved somewhere else as well.
Those paths are implementation details of dconf and gvfs. A lot of GNOME
applications use either dconf or gvfs, so duplicating that information
in every application seems wrong.

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



signature.asc
Description: OpenPGP digital signature

Bug#840840: pocl: Does not build on several architectures

[Andreas Tille]

Hi Andreas,

On Sat, Oct 15, 2016 at 03:59:16PM +0200, Andreas Beckmann wrote:
> Huh? The only architecture with outdated binaries is powerpcspe (which
> only "successfully" built them in the past thanks to a nocheck buildd).
> Feel free to get them decrufted as well.

What about

   arm64: 
https://buildd.debian.org/status/fetch.php?pkg=pocl&arch=arm64&ver=0.13-8&stamp=1476101601
   armhf: 
https://buildd.debian.org/status/fetch.php?pkg=pocl&arch=armhf&ver=0.13-8&stamp=1476101525
   mips:  
https://buildd.debian.org/status/fetch.php?pkg=pocl&arch=mips&ver=0.13-8&stamp=1476107564

and all those others listed here

   https://buildd.debian.org/status/package.php?p=pocl 

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#840847: freezegun: FTBFS under some timezones (eg. GMT-14)

[Chris Lamb]

Source: freezegun
Version: 0.3.6-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs timezones
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

freezegun fails to build from source in logs/unstable undersome timezones (eg. 
TZ="/usr/share/zoneinfo/Etc/GMT-14"):

  [..]

  ==
  FAIL: tests.test_class_import.test_import_localtime
  --
  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
  self.test(*self.arg)
File "/build-2nd/freezegun-0.3.6/freezegun/api.py", line 449, in wrapper
  result = func(*args, **kwargs)
File "/build-2nd/freezegun-0.3.6/tests/test_class_import.py", line 83, in 
test_import_localtime
  assert struct.tm_mday == 14
  AssertionError: 
  time.struct_time(tm_year=2012, tm_mon=1, tm_mday=15, tm_hour=2, tm_min=0, 
tm_sec=0, tm_wday=6, tm_yday=15, tm_isdst=-1) = fake_localtime_function()
  assert time.struct_time(tm_year=2012, tm_mon=1, tm_mday=15, tm_hour=2, 
tm_min=0, tm_sec=0, tm_wday=6, tm_yday=15, tm_isdst=-1).tm_year == 2012
  assert time.struct_time(tm_year=2012, tm_mon=1, tm_mday=15, tm_hour=2, 
tm_min=0, tm_sec=0, tm_wday=6, tm_yday=15, tm_isdst=-1).tm_mon == 1
  >>  assert time.struct_time(tm_year=2012, tm_mon=1, tm_mday=15, tm_hour=2, 
tm_min=0, tm_sec=0, tm_wday=6, tm_yday=15, tm_isdst=-1).tm_mday == 14

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/debian/logs/unstable/amd64/freezegun_0.3.6-1.build2.log.gz

(Note the use of fake_localtime, which is going to vary under such extreme
timezones.)




Regards,

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


freezegun.0.3.6-1.logs.unstable.log.txt.gz
Description: Binary data

Bug#180886: RE:OpenSSL layer of GNUTLS

[Amos Jeffries]

Sadly the GnuTLS support in Squid-3 is quite limited. It is not enough
to consider the current SSL bugs closed.

I am making some progress in Squid-4, but still not quite there and that
version will probably not make it into Stretch. Maybe backports later
next year.

Amos