Bug#700755: closed by Ben Hutchings (Closing bugs assigned to linux-2.6 package)]

[Valentin Vidic]

The machine from the original report has been working stable for
a while now, so I confirm this is probably fixed in wheezy kernels:
linux-image-3.2.0-4-amd64 version 3.2.78-1 running at the moment.

-- 
Valentin

Bug#825359: sbuild: unrealistic figure about total space used

[Johannes Schauer]

Hi,

Quoting Santiago Vila (2016-07-01 02:02:17)
> My .sbuildrc is the one in /usr/share/doc/sbuild/examples/example.sbuildrc.
> 
> My /etc/schroot/chroot.d/stretch file is like this:

thanks, though I still don't see it. :(

To test I created the following very minimal Debian package, consisting just of
d/rules, d/changelog and d/control:

==> debian/changelog <==
sbuild-test-minimal (1.0-1) UNRELEASED; urgency=medium

  * Initial release. (Closes: #XX)

 -- Johannes Schauer   Tue, 28 Jun 2016 23:10:30 +0200

==> debian/control <==
Source: sbuild-test-minimal
Maintainer: Debian buildd-tools Developers 


Package: sbuild-test-minimal-pkg1
Architecture: any

==> debian/rules <==
#!/usr/bin/make -f

clean:
rm -f build debian/files
rm -rf debian/tmp

build:
touch build

binary-indep: build

binary-arch: build
rm -rf debian/tmp
mkdir -p debian/tmp/DEBIAN
dd if=/dev/zero of=debian/tmp/data bs=10M count=1
dpkg-gencontrol
dpkg --build debian/tmp ..

binary: binary-indep binary-arch

build-arch: build

build-indep: build

.PHONY: binary binary-arch binary-indep clean

When I build this package with sbuild I get:

Finished at 20160701-0905
Build needed 00:00:12, 20520k disc space

This sounds exactly plausible because the dd command in d/rules created a 10 MB
file which is now present in d/tmp as well as in the built .deb. As a result,
about 20 MB of space should be needed which is what sbuild prints at the end as
expected.

Santiago, I noticed that you are using a directory type chroot without using
union-type=overlay. Could it be that your /chroot/stretch/build directory
contains leftovers of previous builds?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#829168: misleading indentation in LzmaEnc.c:1350

[Robert Bihlmeyer]

Package: lzma-dev
Version: 9.22-2
Severity: normal

https://sources.debian.net/src/lzma/9.22-2/C/LzmaEnc.c/#L1346

Line 1350 is on the same indentation level as line 1347, which is semantically 
wrong.
Even if line 1349 were not commented out, the style used by this file would 
place the
opening brace at the same level of the if statement.

This minor style issue makes problems for projects including LzmaEnc.c that 
want to compile
with -Werror=misleading-indentation for their own sake. Please consider 
cleaning it up.

Bug#811867: goldencheetah: FTBFS with GCC 6: no matching function for call to

[KURASHIKI Satoru]

hi,

Martin Michlmayr  writes:

> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.

Upstream has already been dealt with:
https://github.com/GoldenCheetah/GoldenCheetah/issues/1973

So, I will close this with importing new upstream tarball.

regards,
--
KURASHIKI Satoru
GPG: 40A2F113

Bug#829145: transition: glibc 2.23

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 01/07/16 01:41, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> We would like to get a transition slot for glibc 2.23. It is currently
> available in experimental and has been built successfully on all
> official architectures except hurd-i386. We have fixed the hurd-i386
> failure in out git, and we are working on build failures for alpha, hppa
> and sparc64. There are due to testsuite issue, mostly in the math parts
> and do not look very critical.
> 
> It should be noted that this upload will make a few packages to FTBFS,
> mostly due to more precise checking in the floating-point classification
> macros (isnan, isinf, ...). In most of the cases the changes just make
> existing bugs visible. The list of affected packages is available [1]
> (thanks to Martin Michlmayr), and the bugs have been opened for more
> than 3 months.
> 
> As the glibc is using symbol versioning, there is no soname change. That
> said a few packages are using libc internal symbols and have to be
> rebuilt for this transition:
>  - apitrace
>  - bro
>  - dante
>  - libnih
>  - libnss-db
>  - unscd
>  
> Here is the corresponding ben file:
>  
> title = "glibc";
> is_affected = .depends ~ /libc[0-9.]* \(< is_good = .depends ~ /libc[0-9.]* \(<< 2.24\)/;
> is_bad = .depends ~ /libc[0-9.]* \(<< 2.23\)/;
> 
> In addition to that, a few new symbols have been added that might
> prevent a few other packages to transition to testing if they pick up
> the new symbols, namely the fts64_* and the lgamma* ones. It should not
> concerns many packages.

Go ahead.

Cheers,
Emilio

Bug#829169: New upstream version 0.32

[Guido Günther]

Source: spice-gtk
Severity: wishlist

virt-viewer 4.0 needs spice-client-gtk 0.31. It would be great to have
this version in the archive. Please let me know if I can help with that.
Cheers,
 -- Guido


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

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

Bug#829074: nmu: opam

[Emilio Pozuelo Monfort]

On 30/06/16 19:11, Gianfranco Costamagna wrote:
> Hi,
> 
>> Scheduled. Let us know if that doesn't help.
> 
> 
> it helped on s390x, however now ppc64el is having the same issue
> Updating dose3 makes 1 non-depending packages uninstallable on ppc64el: opam 
> 
> in Ubuntu we can't rebuild single architectures, so I'm unsure which one 
> needs update
> 
> according to the tracker page, I would guess
> "mips mips64elmipsel  ppc64el"
> 
> https://release.debian.org/transitions/html/ocaml.html
> 
> but not at all an ocaml man :)

Scheduled.

Emilio

Bug#829170: dh_elpa_test: option to run tests inside dtach for tests that need a tty

[Sean Whitton]

Source: dh-elpa
Version: 0.0.21
Severity: wishlist

Some ERT (and possibly Buttercup) test suites need a tty to run.  That
is, they fail under `emacs -batch' while succeeding under `emacs -nw'.

src:evil-el works around this by launching the test suite inside dtach.
This method comes from src:notmuch.  src:evil-el checks the test exit
status but swallows the stdout; src:notmuch manages to display the
stdout (though note that src:notmuch doesn't use ERT or Buttercup).

It would be nice if the user could specify something like

export DH_ELPA_TEST_TTY=yes

in their rules file and dh_elpa_test would take care of it for them.

-- 
Sean Whitton

Bug#828540: sendmail: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Fri, Jul 01, 2016 at 01:47:09AM +0200, Andreas Beckmann wrote:
> 
> Since I'm used to neither openssl nor the sendmail source code (and I 
> have no use for sendmail at all, now that it passes the piuparts 
> tests), I'm not going to write a patch for supporting openssl 1.1.0 
> along 1.0.2.
> Instead I'll wait for either a new upstream release or some patch 
> showing up somewhere, which may mean stretch could ship without 
> sendmail.
> 
> Dear users of sendmail: Your help is needed in case you want to 
> continue using sendmail in stretch!

It's actually on the release team's list of key source packages.
The errors there should be easy to solve, you just need to know
which functions to use.


Kurt

Bug#829171: ruby-nokogiri: breaks redmine

[Jörg-Volker Peetz]

Package: ruby-nokogiri
Version: 1.6.8-1
Severity: normal

Hi Antonio,

upgrading to this version doesn't work and throws the following error
message:

.
.
Processing triggers for redmine (3.2.3-1) ...
Bundler could not find compatible versions for gem "pkg-config":
  In Gemfile:
nokogiri (>= 1.6.7.2) was resolved to 1.6.8, which depends on
  pkg-config (~> 1.1.7)

Could not find gem 'pkg-config (~> 1.1.7)', which is required by gem 'nokogiri
(>= 1.6.7.2)', in any of the sources.
dpkg: error processing package redmine (--unpack):
 subprocess installed post-installation script returned error exit status 6
Processing triggers for mime-support (3.60) ...
Errors were encountered while processing:
 redmine
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up ruby-nokogiri (1.6.8-1) ...
Setting up redmine (3.2.3-1) ...
Bundler could not find compatible versions for gem "pkg-config":
  In Gemfile:
nokogiri (>= 1.6.7.2) was resolved to 1.6.8, which depends on
  pkg-config (~> 1.1.7)

Could not find gem 'pkg-config (~> 1.1.7)', which is required by gem 'nokogiri
(>= 1.6.7.2)', in any of the sources.
dpkg: error processing package redmine (--configure):
 subprocess installed post-installation script returned error exit status 6
.
.

The version of redmine is 3.2.3-1 and of ruby-bundler 1.12.5-1.
I downgraded to the previous version 1.6.7.2-3 with

  dpkg -i ruby-nokogiri_1.6.7.2-3_amd64.deb
  dpkg --configure redmine

Should I have waited for some other package to be upgraded?

Best regards,
jvp.


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

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

Versions of packages ruby-nokogiri depends on:
ii  libc6   2.22-12
ii  libgmp102:6.1.1+dfsg-1
ii  libruby2.3  2.3.1-3
ii  libxml2 2.9.3+dfsg1-1.2
ii  libxslt1.1  1.1.28-4
ii  ruby1:2.3.0+4

ruby-nokogiri recommends no packages.

ruby-nokogiri suggests no packages.

-- no debconf information

Bug#829172: security-tracker: New 'postponed' tag for issues warranting a DSA but postponed while waiting for more serious issues

[Salvatore Bonaccorso]

Package: security-tracker
Severity: wishlist

Hi

It would be nice to have a new tag handled in similar way to 'no-dsa'
called 'postponed'.

In some cases a issue warrants a DSA, but can be postponed until more
urgent issues appear for that given package. Currently those are mared
in free text form usually like

[jessie] - foo  (Can be included in future DSA)

but that is prone to be forgotten when preparing then the update for
foo. It thus will be nice to be able to distinct cases which are
really just  and those which warrants a DSA, but can be
postponed, and thus be marked e.g.

[jessie] - foo 

It though need evaluation which parts of the tracker/cronjobs/scripts
would be affected by such a change.

Regards,
Salvatore

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

Hello,

On Thu, Jun 30, 2016 at 10:28:13PM +0300, Dmitry Bogatov wrote:
> I elaborated this solution and pushed to master. Following is true:
> 
>  * `make test < /dev/null' fails
>  * `dpkg-buildpackage -us -uc < /dev/null' is success now. (see 16d89)
>  * 'dtach' uses pty(7)
>  * default configuration of pbuilder do not provide possibility to allocate
>pty

Nice job.

I filed #829170 and committed a comment to your d/rules referring to that.

On Thu, Jun 30, 2016 at 10:24:51PM +0200, Jakub Wilk wrote:
> * Dmitry Bogatov , 2016-06-30, 22:28:
> >* default configuration of pbuilder do not provide possibility to allocate
> >pty
> 
> Sounds like a bug in pbuilder.
> 
> >So, question is whether it is possible to allocate pty on Debian build
> >farm.
> 
> Yes.

It seems that vanilla sbuild has the same problem (tested locally and on
deb-o-matic), so it seems like the buildds are using some special sbuild
configuration to permit allocating ptys.

I would be grateful, Jakub, if you could try the build on your sbuild
config before I file a bug against sbuild suggesting this be the
default.  The repo, for your convenience:
https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el

> > > > Nice work.  Have you forwarded the fix upstream?
> > > Too much trouble. To fix it upstream, they have to deal with either:
> > >  * evil mode is autoloaded, interactive and with sane description. 
> > > Ugliness
> > >in code.
> 
> > Do you know whether the problem if Debian-specific, or if it also arises
> > when installing evil from MELPA?
> 
> On MELPA everything is smooth.

Are you sure about this?  I tested myself, and the same problem occurs:
M-x evil-mode doesn't work, although M-x describe-function evil-mode does.

I consider this an upstream bug.  Although most users will call
`evil-mode' in their init file, one of the reasons for using the
package.el packaging format is that a user can just do `M-x
package-install evil RET M-x evil-mode RET' to quickly try out a new
mode without doing any config.

Since we have fixed this bug in the Debian package, we ought to forward
our work upstream.  Since we fixed it by some code in d/rules, we can't
just send a patch they can apply.  So I suggest that you file an
upstream bug report, explain what you did to fix the problem for the
Debian package, and put a link to that bug report in the Forwarded:
header of the patch and also as a comment in d/rules.

Another thing :)  I don't think you need to invoke find(1) in d/rules.
You can just do something like this:

sed -i 's#foo..' 
debian/elpa-evil/usr/share/emacs/site-lisp/elpa-src/evil-*/evil-autoloads.el

That's more explicit and easier to understand.

-- 
Sean Whitton

Bug#829173: swiginac: FTBFS: /usr/include/ginac/ptr.h:37:13: error: expected '; ' at end of member declaration

[Emilio Pozuelo Monfort]

Source: swiginac
Version: 1.5.1.1-2
Severity: serious

On a rebuild against the new ginac, your package failed to build everywhere:

creating build/temp.linux-x86_64-2.7
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC 
-I/usr/include/python2.7 -c swiginac_wrap.cpp -o 
build/temp.linux-x86_64-2.7/swiginac_wrap.o
cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC 
but not for C++
In file included from /usr/include/ginac/basic.h:27:0,
 from /usr/include/ginac/ginac.h:28,
 from swiginac_wrap.cpp:3305:
/usr/include/ginac/ptr.h:37:13: error: expected ';' at end of member declaration
  refcounted() noexcept : refcount(0) {}
 ^
/usr/include/ginac/ptr.h:37:15: error: 'noexcept' does not name a type
  refcounted() noexcept : refcount(0) {}
   ^
/usr/include/ginac/ptr.h:37:15: note: C++11 'noexcept' only available with 
-std=c++11 or -std=gnu++11
/usr/include/ginac/ptr.h:39:29: error: expected ';' at end of member declaration
  unsigned int add_reference() noexcept { return ++refcount; }
[...]

Apparently ginac requires C++11 now, which you need to manually enable with GCC 
5.

Full logs at:

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

Emilio

Bug#811595: FTBFS with GCC 6: statement indented as if it were guarded by

[Robert Bihlmeyer]

Package: upx-ucl
Followup-For: Bug #811595

Note: I’ve opened bug#829168 for one lzma issue reported here.

Bug#829174: beast-mcmc: depends on package in contrib

[Jakub Wilk]

Source: beast-mcmc
Version: 1.8.4+dfsg-1
Severity: grave

beast-mcmc is main, but it depends on libnucleotidelikelihoodcore0, 
which is in contrib.


This is violation of Policy §2.2.1, and it makes the package 
uninstallable for users who didn't enable contrib.


--
Jakub Wilk

Bug#829178: python-tidylib: FTBFS, test failures with tidy-html5

[Jeremy Bicha]

Source: python-tidylib
Version: 0.2.4~dfsg-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Forwarded: https://github.com/countergram/pytidylib/issues/13


Hi, python-tidylib fails to build from source with tidy-html5 because
of test failures.

You can see the failed tests at the upstream bug.

Thanks,
Jeremy Bicha

Bug#829175: Missing dependency on ruby-pkg-config

[Duck]

Package: ruby-nokogiri
Version: 1.6.8-1
Severity: serious


Quack,

-
$ vagrant up
Vagrant experienced a version conflict with some installed plugins!
This usually happens if you recently upgraded Vagrant. As part of the
upgrade process, some existing plugins are no longer compatible with
this version of Vagrant. The recommended way to fix this is to remove
your existing plugins and reinstall them one-by-one. To remove all
plugins:

rm -r ~/.vagrant.d/plugins.json ~/.vagrant.d/gems

Note if you have an alternate VAGRANT_HOME environmental variable
set, the folders above will be in that directory rather than your
user's home directory.

The error message is shown below:

Bundler could not find compatible versions for gem "pkg-config":
  In Gemfile:
vagrant (= 1.8.4) was resolved to 1.8.4, which depends on
  nokogiri was resolved to 1.6.8, which depends on
pkg-config (~> 1.1.7)

Could not find gem 'pkg-config (~> 1.1.7)', which is required by gem
'nokogiri', in any of the sources.
-

Indeed installing ruby-pkg-config solves the problem.

You can see the runtime dep in:

/usr/share/rubygems-integration/2.3.0/specifications/nokogiri-1.6.8.gemspec
but the package lacks it.

\_o<

Bug#829177: bugs.debian.org: use release tags to adjust the version graph

[Paul Wise]

Package: bugs.debian.org
Severity: wishlist

Debian Bug #817528 has no found version but is tagged sid stretch. It
would be nice if the version graph paid attention to the release tags
so that versions before stretch/sid are marked as boring. The version
ovals/rectangles containing the release names from the tags could also
be highlighted in some way, perhaps a different outline/shape/colour.

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#829147: tidy-html5: Please drop unnecessary dependency on libdmalloc-dev

[Daniel James]

Hi Steve,

> A close inspection shows that dmalloc is not actually a requirement of
> libtidy-dev; the dmalloc header is included only if one explicitly #defines
> DMALLOC in the calling code.  libtidy is certainly not linking to / using
> dmalloc's implementation at build time.

Thanks for the report. This package is in collab-maint and the
dependency was not added by me:

http://anonscm.debian.org/cgit/collab-maint/tidy-html5.git/commit/?id=e0d22c87c157c74e2f9beae828e3b8c592b267cf

I have cc'd the author and committer for further discussion, as I'm
assuming there was a good reason for this change. However the commit is
not linked to a bug ticket so I have no further details, sorry.

Cheers!

Daniel

Bug#829180: mounts sometimes fail at boot

[Daniel Pocock]

Severity: important
Package: systemd
Version: 215-17+deb8u2

Since upgrading to jessie/systemd, one particular system frequently
stops in the single-user mode password prompt during booting.

Looking at the journalctl output, I usually find that some mount has
failed with a line like this:


/dev/mapper/vg00-name device already mounted or /foo/bar/mountpoint busy


The actual mountpoint is not the same each time the error occurs.

Sometimes there is more than one filesystem that fails to mount.

The system is an NFS server but it doesn't mount any NFS shares from
other servers.

In every case where I saw this happen, the system had been shut down
cleanly before the boot.

When this occurred today, I noticed that the mountpoint was on the root
filesystem (e.g. /foo/bar/mountpoint is a directory in /) so it doesn't
appear to be waiting for any other mount.

The problem always seems to refer to LVM logical volumes.

I previously had a lot more logical volumes on this machine but I've
combined several of them into a BtrFS volume because I thought that
having too many LVs may be troublesome.  Now there are 10 LVs.

It was working fine with over 50 LVs with wheezy, before systemd

Regards,

Daniel

Bug#828900: python-tidylib: FTBFS: ! LaTeX Error: File `iftex.sty' not found.

[Jeremy Bicha]

Control: tags -1 + patch

This patch still isn't enough for it to build because of test
failures. See the other RC bug on this package.

Thanks,
Jeremy


>From 88fa457654cb37802bd89073aae234f3e130cac7 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Thu, 30 Jun 2016 01:36:21 -0400
Subject: [PATCH 1/2] Update dependencies for tidy-html5 and texlive (Closes:
 #828900)

---
 debian/changelog | 9 +
 debian/control   | 7 ---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 94a35b2..d24bc84 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,16 @@
 python-tidylib (0.2.4~dfsg-3) UNRELEASED; urgency=medium

+  * Team upload.
+
+  [ Ondřej Nový ]
   * Fixed VCS URL (https)

+  [ Jeremy Bicha ]
+  * debian/control:
+- Build-Depend on libtidy-dev
+- Depend on libtidy5 instead of libtidy-0.99-0
+- Build-depend on texlive-generic-extra for iftex.sty (Closes: #828900)
+
  -- Ondřej Nový   Tue, 29 Mar 2016 22:24:55 +0200

 python-tidylib (0.2.4~dfsg-2) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index d96d3ed..1f875d3 100644
--- a/debian/control
+++ b/debian/control
@@ -8,8 +8,9 @@ Build-Depends: debhelper (>= 9),
python-all (>= 2.6.6-3~),
python3-all,
python3-sphinx,
-   libtidy-0.99-0,
+   libtidy-dev,
texlive-fonts-recommended,
+   texlive-generic-extra,
texlive-latex-extra
 Standards-Version: 3.9.6
 Homepage: http://countergram.com/open-source/pytidylib/
@@ -18,7 +19,7 @@ Vcs-Browser:
https://anonscm.debian.org/cgit/python-modules/packages/python-tidy

 Package: python-tidylib
 Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, libtidy-0.99-0
+Depends: ${misc:Depends}, ${python:Depends}, libtidy5
 Description: Python 2 wrapper for HTML Tidy (tidylib)
  PyTidyLib is a Python package that wraps the HTML Tidy library. This allows
  you, from Python code, to “fix” invalid (X)HTML markup. Some of the library’s
@@ -36,7 +37,7 @@ Description: Python 2 wrapper for HTML Tidy (tidylib)

 Package: python3-tidylib
 Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}, libtidy-0.99-0
+Depends: ${misc:Depends}, ${python3:Depends}, libtidy5
 Description: Python 3 wrapper for HTML Tidy (tidylib)
  PyTidyLib is a Python package that wraps the HTML Tidy library. This allows
  you, from Python code, to “fix” invalid (X)HTML markup. Some of the library’s
-- 
2.8.1

Bug#829179: binfmt-support.service activating (start) for ever, no console

[helix84]

Package: binfmt-support
Version: 2.1.5-1
Followup-For: Bug #778881


Just happened to me for the first time today. Rebooted via Alt-SysRq.
It didn't occur to me to try logging in via ssh.

Here's the last successful message from /var/log/messages before I
gave up waiting:

Jul  1 10:03:31 fujitsu kernel: [   78.602318] IPv6:
ADDRCONF(NETDEV_UP): docker0: link is not ready
Jul  1 10:11:12 fujitsu kernel: [  538.823954] SysRq : Emergency Sync

In /var/log/sysslog, I can see many of these messages (every second):

Jul  1 10:11:41 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:42 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:43 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:44 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:45 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:46 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:48 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:49 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:49 fujitsu kernel: [  575.582565] SysRq : Emergency Sync
Jul  1 10:11:49 fujitsu kernel: [  575.591001] Emergency Sync complete
Jul  1 10:11:50 fujitsu kernel: [  576.661584] SysRq : This sysrq
operation is disabled.
Jul  1 10:11:50 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:51 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:52 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:53 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:55 fujitsu systemd[1]: Looping too fast. Throttling
execution a little.
Jul  1 10:11:55 fujitsu kernel: [  582.224546] SysRq : Emergency Remount R/O
Jul  1 10:13:58 fujitsu rsyslogd: [origin software="rsyslogd"
swVersion="8.4.2" x-pid="1185" x-info="http://www.rsyslog.com";] start


Could be related to #789796.


Regards,
~~helix84

Bug#829176: libapache-htpasswd-perl: FTBFS: dh_clean: Please specify the compatibility level in debian/compat

[Chris Lamb]

Source: libapache-htpasswd-perl
Version: 1.8-1.1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

libapache-htpasswd-perl fails to build from source in unstable/amd64:

  [..]

  
  
**
  ** Starting build 
  **
  
**
  
   Package:  libapache-htpasswd-perl
   Version:  1.8-1.1
   Build architecture:   amd64
   Date: Fri, 01 Jul 2016 10:25:20 +0200
   Hostname: 181df15f8f76
   Uname:Linux 181df15f8f76 4.6.0-1-amd64 #1 SMP Debian 4.6.2-2 
(2016-06-25) x86_64 GNU/Linux
   /etc/timezone:Africa/Johannesburg
  
  
**
  ** Installing build dependencies  
  **
  
**
  
  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'libapache-htpasswd-perl-build-deps' in 
'../libapache-htpasswd-perl-build-deps_1.8-1.1_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package libapache-htpasswd-perl-build-deps.
  (Reading database ... 23081 files and directories currently installed.)
  Preparing to unpack libapache-htpasswd-perl-build-deps_1.8-1.1_all.deb ...
  Unpacking libapache-htpasswd-perl-build-deps (1.8-1.1) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
cdbs libcrypt-passwdmd5-perl
  The following NEW packages will be installed:
cdbs libcrypt-passwdmd5-perl
  0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 91.2 kB of archives.
  After this operation, 341 kB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 cdbs all 0.4.142 
[80.7 kB]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 
libcrypt-passwdmd5-perl all 1.3-10 [10.5 kB]
  Fetched 91.2 kB in 0s (0 B/s)
  Selecting previously unselected package cdbs.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 23085 files and directories currently installed.)
  Preparing to unpack .../archives/cdbs_0.4.142_all.deb ...
  Unpacking cdbs (0.4.142) ...
  Selecting previously unselected package libcrypt-passwdmd5-perl.
  Preparing to unpack .../libcrypt-passwdmd5-perl_1.3-10_all.deb ...
  Unpacking libcrypt-passwdmd5-perl (1.3-10) ...
  Processing triggers for man-db (2.7.5-1) ...
  Setting up cdbs (0.4.142) ...
  Setting up libcrypt-passwdmd5-perl (1.3-10) ...
  Setting up libapache-htpasswd-perl-build-deps (1.8-1.1) ...
  
  
**
  ** Environment
  **
  
**
  
  
PATH=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  HOSTNAME=181df15f8f76
  TERM=xterm
  PAGER=more
  DISPLAY=:0
  DOCKER_IMAGE=lamby-debian-sid
  DEB_BUILD_OPTIONS=parallel=9
  PIP_DOWNLOAD_CACHE=/home/lamby/.cache/pip
  HOME=/home/lamby
  LOGNAME=lamby
  SHLVL=1
  
PWD=/home/lamby/temp/cdt.20160701102518.MLxrRVHm9O.libapache-htpasswd-perl/libapache-htpasswd-perl-1.8
  OLDPWD=/home/lamby/temp/cdt.20160701102518.MLxrRVHm9O.libapache-htpasswd-perl
  GPG_TTY=/dev/console
  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**

Bug#826059: #826059 java may crash when loading a class named java

[Sharma, Alok Kumar (OSTL)]

I just reviewed and validated the fix provided by Evgeny Kapun. And it looks 
fine !!

I thought to share some description of this defect.

Please consider the code in



File: hotspot/src/share/vm/classfile/systemDictionary.cpp

Function: SystemDictionary::resolve_from_stream

Code snippet:

-

  TempNewSymbol parsed_name = NULL;



  // Parse the stream. Note that we do this even though this klass might

  // already be present in the SystemDictionary, otherwise we would not

  // throw potential ClassFormatErrors.

  //

  // Note: "name" is updated.



  instanceKlassHandle k = ClassFileParser(st).parseClassFile(class_name,

 loader_data,

 protection_domain,

 parsed_name,

 verify,

 THREAD);



  const char* pkg = "java/";

  if (!HAS_PENDING_EXCEPTION &&

  !class_loader.is_null() &&

  parsed_name != NULL &&

  !strncmp((const char*)parsed_name->bytes(), pkg, strlen(pkg))) {  
//<-- (A)

// It is illegal to define classes in the "java." package from

// JVM_DefineClass or jni_DefineClass unless you're the bootclassloader

ResourceMark rm(THREAD);

char* name = parsed_name->as_C_string();

char* index = strrchr(name, '/');

*index = '\0'; // chop to just the package name

while ((index = strchr(name, '/')) != NULL) {

  *index = '.'; // replace '/' with '.' in package name

}

const char* fmt = "Prohibited package name: %s";

size_t len = strlen(fmt) + strlen(name);

char* message = NEW_RESOURCE_ARRAY(char, len);

jio_snprintf(message, len, fmt, name);

Exceptions::_throw_msg(THREAD_AND_LOCATION,

  vmSymbols::java_lang_SecurityException(), message);

  }

--

The reason of the defect is the "strncmp" call marked as (A).
The condition was added to detect a "parsed_name" starting with "java/". This 
is to avoid users defining classes in "java.".
Please note the arguments to "strncmp" are
First argument: Character sequence (Not terminated with NULL but defined with 
length parsed_name->utf8_length())
Second argument: Character array (Null terminated character string, length can 
be found using "strlen")
Third argument: Length of second argument.

Please note that "strncmp" call works well
-when both the strings to be compared are NULL 
terminated character sequence (string)
-Or, The length of character sequence (not 
terminating with NULL) is greater than the length of NULL terminated string.

The case in consideration due to implementation of name storage logic. The 
names are stored in character array buffer. This string is not terminated with 
NULL, but are defined with length stored in another field of data structure.

But for other cases we end up comparing characters beyond the actual length of 
first argument. That can produce unpredictable results.
Example:

String "java" is stored as (name part of java.java)
Length=4,location -->|j|a|v|a|||

In our failed case strncmp, compares 5 characters, the fifth character can be 
anything if it happens to be fifth character of second string ('/') then the 
code would report wrong match.

But for other cases we end up comparing characters beyond the actual length of 
first argument. That can produce unpredictable results.

Patch suggested by submitter is


--

--- a/hotspot/src/share/vm/classfile/systemDictionary.cpp

+++ b/hotspot/src/share/vm/classfile/systemDictionary.cpp

@@ -1087,6 +1087,7 @@

   if (!HAS_PENDING_EXCEPTION &&

   !class_loader.is_null() &&

   parsed_name != NULL &&

+  parsed_name->utf8_length() >= strlen(pkg) &&

   !strncmp((const char*)parsed_name->bytes(), pkg, strlen(pkg))) {

 // It is illegal to define classes in the "java." package from

 // JVM_DefineClass or jni_DefineClass unless you're the bootclassloade

--

Additional check solves the issue.

Regards,
Alok Kumar Sharma
Hewlett Packard Enterprise

Bug#829147: tidy-html5: Please drop unnecessary dependency on libdmalloc-dev

[Gianfranco Costamagna]

Hi Steve,


>http://anonscm.debian.org/cgit/collab-maint/tidy-html5.git/commit/?id=e0d22c87c157c74e2f9beae828e3b8c592b267cf
>
>I have cc'd the author and committer for further discussion, as I'm
>assuming there was a good reason for this change. However the commit is
>not linked to a bug ticket so I have no further details, sorry.


I addded it because of a grep for includes, and Suggests is the best thing to 
avoid
an Ubuntu delta.
thanks for making it migrate and MIR'ing it :)

By change I forwarded privately a mail to ask to integrate your patch before 
seeing this bug report, thanks
for reporting it!

G.

Bug#829128: harfbuzz: Please provide a backport or allow me to do it)

[Emilio Pozuelo Monfort]

Hi Lisandro,

On 30/06/16 21:11, Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! I'm currently backporting Qt 5.6.1 to jessie. I would like to avoid using
> Qt's harfbuzz embedded copy and so would need a harfbuzz backport.
> 
> I have just made a full rebuild using pure jessie packages without isues.
> 
> Ideally it would be really great if you could provide the backport, else
> I can do it myself, for which I would like your approval.

You have my blessing :)

Cheers,
Emilio

Bug#786524: file: Wrong return code on non existant file

[Christoph Biedl]

Lionel Felicite wrote...

> even on fresh install, file returns O even if a file/directory
> (directory in my case) doesn't exist

This behaviour, although a bit surprising, is actually a feature. Use
file's -E option to get a non-zero exit code in such a situation.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/file.html#tag_20_46_10

states:

| If the file named by the file operand does not exist, cannot be read,
| or the type of the file named by the file operand cannot be
| determined, this shall not be considered an error that affects the
| exit status.

The upstream bug report about this can be found at
http://bugs.gw.com/view.php?id=316

Regards,

Christoph


signature.asc
Description: Digital signature

Bug#825359: sbuild: unrealistic figure about total space used

[Santiago Vila]

On Fri, 1 Jul 2016, Johannes Schauer wrote:

> Santiago, I noticed that you are using a directory type chroot without using
> union-type=overlay. Could it be that your /chroot/stretch/build directory
> contains leftovers of previous builds?

That both can't be and should not be :-)

It "can't be" because even if du is accounting for any leftover,
in either case the reported space would never be higher than the disk
size (I don't have such a big disk).

Also, it "should not be" because sbuild creates a temporary directory in
/chroot/stretch/build named

/chroot/stretch/build/sourcename-randomstring

I want to believe that the "du" command is performed on this last
directory, not on its parent, but I will leave this to you to check,
since you know the code a lot better than me.

Thanks.

Bug#811744: Still not fixed, please re-open

[Roderich Schupp]

Build with gcc-6 of libraw 0.17.2-3 fails with

internal/dcraw_common.cpp: In member function ‘void
LibRaw::vng_interpolate()’:
internal/dcraw_common.cpp:4539:3: error: narrowing conversion of ‘128’ from
‘int’ to ‘signed char’ inside { } [-Wnarrowing]
   }, chood[] = { -1,-1, -1,0, -1,+1, 0,+1, +1,+1, +1,0, +1,-1, 0,-1 };
   ^
internal/dcraw_common.cpp:4539:3: error: narrowing conversion of ‘136’ from
‘int’ to ‘signed char’ inside { } [-Wnarrowing]
internal/dcraw_common.cpp:4539:3: error: narrowing conversion of ‘128’ from
‘int’ to ‘signed char’ inside { } [-Wnarrowing]
internal/dcraw_common.cpp:4539:3: error: narrowing conversion of ‘136’ from
‘int’ to ‘signed char’ inside { } [-Wnarrowing]
internal/dcraw_common.cpp:4539:3: error: narrowing conversion of ‘128’ from
‘int’ to ‘signed char’ inside { } [-Wnarrowing]
internal/dcraw_common.cpp:4539:3: error: narrowing conversion of ‘136’ from
‘int’ to ‘signed char’ inside { } [-Wnarrowing]
Makefile:863: recipe for target 'internal/dcraw_common.lo' failed
make[1]: *** [internal/dcraw_common.lo] Error 1
make[1]: Leaving directory '/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
Command exited with non-zero status 2


While 0001-Fix_dcraw_narrowing_for_gcc6.patch fixes dcraw/dcraw.c, it
doesn't  modify internal/dcraw_common.cpp
which is derived (pre-processed) from the latter, cf. the "regenerate"
target in Makefile.devel.

Cheers, Roderich

Bug#829182: tidy: package description still talks about HTML 4.0

[Justin B Rye]

Package: tidy
Version: 1:5.2.0-1.1
Severity: wishlist
Tags: patch

First, thank you for packaging tidy-html5!

My complaint is just that the package description hasn't been updated
this millennium.  A remarkable amount of it is still fine, but there's
one line that definitely needs updating, where it says that tidy
"[...] has a comprehensive knowledge of the attributes defined in the
HTML 4.0 recommendation from W3C, and [...]".

You might want to use the obvious minimal fix "s/4/5/", but it'll be
5.1 soon; and besides, tidy can handle more than just HTML, and knows
more about the specs than just the bits about "attributes".  My patch
rephrases it to say that tidy "[...] has a comprehensive knowledge of
the W3C recommendations for HTML/XHTML/XML, and [...]".

Oh, one other thing: there's what seems to be a surplus article in the
clause about encodings, where it says "and understands the US ASCII,
ISO Latin-1, UTF-8 and the ISO 2022 family of 7-bit encodings".  Given
that UTF-8 isn't 7-bit, it can't be saying "the X/Y/Z 7-bit
encodings"; it must be trying to say "X, Y, and the Z encodings", so
I've taken out the first article.  I've also added an IANA-conformant
hyphen to "US-ASCII".

It's possible that the final line saying "Tidy is a product of the
World Wide Web Consortium" may want an update to something explicitly
mentioning HTML5 and HTACG.  I'll leave that up to you.

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

Kernel: Linux 4.6.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)

Versions of packages tidy depends on:
ii  dpkg  1.18.7
ii  libc6 2.22-11
ii  libtidy5  1:5.2.0-1.1

tidy recommends no packages.

tidy suggests no packages.

-- no debconf information

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ru tidy-html5-5.2.0.pristine/debian/control tidy-html5-5.2.0/debian/control
--- tidy-html5-5.2.0.pristine/debian/control	2016-06-08 14:09:39.0 +0100
+++ tidy-html5-5.2.0/debian/control	2016-06-27 11:42:57.221243947 +0100
@@ -13,9 +13,9 @@
 Description: HTML syntax checker and reformatter
  Corrects markup in a way compliant with the latest standards, and
  optimal for the popular browsers.  It has a comprehensive knowledge
- of the attributes defined in the HTML 4.0 recommendation from W3C,
- and understands the US ASCII, ISO Latin-1, UTF-8 and the ISO 2022
- family of 7-bit encodings.  In the output:
+ of the W3C recommendations for HTML/XHTML/XML, and understands
+ US-ASCII, ISO Latin-1, UTF-8 and the ISO 2022 family of 7-bit
+ encodings.  In the output:
  .
   * HTML entity names for characters are used when appropriate.
   * Missing attribute quotes are added, and mismatched quotes found.

Bug#829183: maven-compiler-plugin: FTBFS: Could not resolve dependencies for project org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:3.2

[Chris Lamb]

Source: maven-compiler-plugin
Version: 3.2-5
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

maven-compiler-plugin fails to build from source in unstable/amd64:

  [..]

  Adding debian:AddTrust_Public_Services_Root.pem
  Adding debian:AddTrust_Qualified_Certificates_Root.pem
  Adding debian:AffirmTrust_Commercial.pem
  Adding debian:AffirmTrust_Networking.pem
  Adding debian:AffirmTrust_Premium.pem
  Adding debian:AffirmTrust_Premium_ECC.pem
  Adding debian:ApplicationCA_-_Japanese_Government.pem
  Adding debian:Atos_TrustedRoot_2011.pem
  Adding debian:Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem
  Adding debian:Baltimore_CyberTrust_Root.pem
  Adding debian:Buypass_Class_2_CA_1.pem
  Adding debian:Buypass_Class_2_Root_CA.pem
  Adding debian:Buypass_Class_3_Root_CA.pem
  Adding debian:CA_Disig.pem
  Adding debian:CA_Disig_Root_R1.pem
  Adding debian:CA_Disig_Root_R2.pem
  Adding debian:CA_WoSign_ECC_Root.pem
  Adding debian:CFCA_EV_ROOT.pem
  Adding debian:CNNIC_ROOT.pem
  Adding debian:COMODO_Certification_Authority.pem
  Adding debian:COMODO_ECC_Certification_Authority.pem
  Adding debian:COMODO_RSA_Certification_Authority.pem
  Adding debian:Camerfirma_Chambers_of_Commerce_Root.pem
  Adding debian:Camerfirma_Global_Chambersign_Root.pem
  Adding debian:Certification_Authority_of_WoSign_G2.pem
  Adding debian:Certigna.pem
  Adding debian:Certinomis_-_Autorité_Racine.pem
  Adding debian:Certinomis_-_Root_CA.pem
  Adding debian:Certplus_Class_2_Primary_CA.pem
  Adding debian:Certum_Root_CA.pem
  Adding debian:Certum_Trusted_Network_CA.pem
  Adding debian:Chambers_of_Commerce_Root_-_2008.pem
  Adding 
debian:China_Internet_Network_Information_Center_EV_Certificates_Root.pem
  Adding debian:ComSign_CA.pem
  Adding debian:Comodo_AAA_Services_root.pem
  Adding debian:Comodo_Secure_Services_root.pem
  Adding debian:Comodo_Trusted_Services_root.pem
  Adding debian:Cybertrust_Global_Root.pem
  Adding debian:D-TRUST_Root_Class_3_CA_2_2009.pem
  Adding debian:D-TRUST_Root_Class_3_CA_2_EV_2009.pem
  Adding debian:DST_ACES_CA_X6.pem
  Adding debian:DST_Root_CA_X3.pem
  Adding debian:Deutsche_Telekom_Root_CA_2.pem
  Adding debian:DigiCert_Assured_ID_Root_CA.pem
  Adding debian:DigiCert_Assured_ID_Root_G2.pem
  Adding debian:DigiCert_Assured_ID_Root_G3.pem
  Adding debian:DigiCert_Global_Root_CA.pem
  Adding debian:DigiCert_Global_Root_G2.pem
  Adding debian:DigiCert_Global_Root_G3.pem
  Adding debian:DigiCert_High_Assurance_EV_Root_CA.pem
  Adding debian:DigiCert_Trusted_Root_G4.pem
  Adding debian:E-Tugra_Certification_Authority.pem
  Adding debian:EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.pem
  Adding debian:EC-ACC.pem
  Adding debian:EE_Certification_Centre_Root_CA.pem
  Adding debian:Entrust.net_Premium_2048_Secure_Server_CA.pem
  Adding debian:Entrust_Root_Certification_Authority.pem
  Adding debian:Entrust_Root_Certification_Authority_-_EC1.pem
  Adding debian:Entrust_Root_Certification_Authority_-_G2.pem
  Adding debian:Equifax_Secure_CA.pem
  Adding debian:Equifax_Secure_Global_eBusiness_CA.pem
  Adding debian:Equifax_Secure_eBusiness_CA_1.pem
  Adding debian:GeoTrust_Global_CA.pem
  Adding debian:GeoTrust_Global_CA_2.pem
  Adding debian:GeoTrust_Primary_Certification_Authority.pem
  Adding debian:GeoTrust_Primary_Certification_Authority_-_G2.pem
  Adding debian:GeoTrust_Primary_Certification_Authority_-_G3.pem
  Adding debian:GeoTrust_Universal_CA.pem
  Adding debian:GeoTrust_Universal_CA_2.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R4.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R5.pem
  Adding debian:GlobalSign_Root_CA.pem
  Adding debian:GlobalSign_Root_CA_-_R2.pem
  Adding debian:GlobalSign_Root_CA_-_R3.pem
  Adding debian:Global_Chambersign_Root_-_2008.pem
  Adding debian:Go_Daddy_Class_2_CA.pem
  Adding debian:Go_Daddy_Root_Certificate_Authority_-_G2.pem
  Adding debian:Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem
  Adding debian:Hongkong_Post_Root_CA_1.pem
  Adding debian:IGC_A.pem
  Adding debian:IdenTrust_Commercial_Root_CA_1.pem
  Adding debian:IdenTrust_Public_Sector_Root_CA_1.pem
  Adding debian:Izenpe.com.pem
  Adding debian:Juur-SK.pem
  Adding debian:Microsec_e-Szigno_Root_CA.pem
  Adding debian:Microsec_e-Szigno_Root_CA_2009.pem
  Adding debian:NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem
  Adding debian:NetLock_Business_=Class_B=_Root.pem
  Adding debian:NetLock_Express_=Class_C=_Root.pem
  Adding debian:NetLock_Notary_=Class_A=_Root.pem
  Adding debian:NetLock_Qualified_=Class_QA=_Root.pem
  Adding debian:Network_Solutions_Certificate_Authority.pem
  Adding debian:OISTE_WISeKey_Global_Root_GA_CA.pem
  Adding debian:OISTE_WISeKey_Global_Root_GB_CA.pem
  Adding debian:PSCProcert.pem
  Adding debian:QuoVadis_Root_CA.pem
  Adding debian:QuoVadis_Root_CA_1_G3.pem
  Adding debian:QuoVadis_Root_CA_2.pem
  Addin

Bug#829181: louie: FTBFS: dh_clean: Please specify the compatibility level in debian/compat

[Chris Lamb]

Source: louie
Version: 1.1-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

louie fails to build from source in unstable/amd64:

  [..]

  
  
**
  ** Starting build 
  **
  
**
  
   Package:  louie
   Version:  1.1-2
   Build architecture:   amd64
   Date: Fri, 01 Jul 2016 10:45:08 +0200
   Hostname: 13e4dbf267c5
   Uname:Linux 13e4dbf267c5 4.6.0-1-amd64 #1 SMP Debian 4.6.2-2 
(2016-06-25) x86_64 GNU/Linux
   /etc/timezone:Africa/Johannesburg
  
  
**
  ** Installing build dependencies  
  **
  
**
  
  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'louie-build-deps' in 
'../louie-build-deps_1.1-2_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package louie-build-deps.
  (Reading database ... 23081 files and directories currently installed.)
  Preparing to unpack louie-build-deps_1.1-2_all.deb ...
  Unpacking louie-build-deps (1.1-2) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
cdbs libexpat1-dev libpython-dev libpython2.7 libpython2.7-dev python-dev
python-setuptools python2.7-dev
  Suggested packages:
python-setuptools-doc
  The following NEW packages will be installed:
cdbs libexpat1-dev libpython-dev libpython2.7 libpython2.7-dev python-dev
python-setuptools python2.7-dev
  0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 29.6 MB of archives.
  After this operation, 46.5 MB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 cdbs all 0.4.142 
[80.7 kB]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 libpython2.7 amd64 
2.7.12-1 [1069 kB]
  Get:3 http://httpredir.debian.org/debian sid/main amd64 libexpat1-dev amd64 
2.2.0-1 [128 kB]
  Get:4 http://httpredir.debian.org/debian sid/main amd64 libpython2.7-dev 
amd64 2.7.12-1 [27.8 MB]
  Get:5 http://httpredir.debian.org/debian sid/main amd64 libpython-dev amd64 
2.7.11-2 [19.8 kB]
  Get:6 http://httpredir.debian.org/debian sid/main amd64 python2.7-dev amd64 
2.7.12-1 [282 kB]
  Get:7 http://httpredir.debian.org/debian sid/main amd64 python-dev amd64 
2.7.11-2 [1128 B]
  Get:8 http://httpredir.debian.org/debian sid/main amd64 python-setuptools all 
20.10.1-1.1 [203 kB]
  Fetched 29.6 MB in 0s (57.9 MB/s)
  Selecting previously unselected package cdbs.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 23085 files and directories currently installed.)
  Preparing to unpack .../archives/cdbs_0.4.142_all.deb ...
  Unpacking cdbs (0.4.142) ...
  Selecting previously unselected package libpython2.7:amd64.
  Preparing to unpack .../libpython2.7_2.7.12-1_amd64.deb ...
  Unpacking libpython2.7:amd64 (2.7.12-1) ...
  Selecting previously unselected package libexpat1-dev:amd64.
  Preparing to unpack .../libexpat1-dev_2.2.0-1_amd64.deb ...
  Unpacking libexpat1-dev:amd64 (2.2.0-1) ...
  Selecting previously unselected package libpython2.7-dev:amd64.
  Preparing to unpack .../libpython2.7-dev_2.7.12-1_amd64.deb ...
  Unpacking libpython2.7-dev:amd64 (2.7.12-1) ...
  Selecting previously unselected package libpython-dev:amd64.
  Preparing to unpack .../libpython-dev_2.7.11-2_amd64.deb ...
  Unpacking libpython-dev:amd64 (2.7.11-2) ...
  Selecting previously unselected package python2.7-dev.
  Preparing to unpack .../python2.7-dev_2.7.12-1_amd64.deb ...
  Unpacking python2.7-dev (2.7.12-1) ...
  Sel

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> > > > > Nice work.  Have you forwarded the fix upstream?
> > > > Too much trouble. To fix it upstream, they have to deal with either:
> > > >  * evil mode is autoloaded, interactive and with sane description. 
> > > > Ugliness
> > > >in code.
> >
> > > Do you know whether the problem if Debian-specific, or if it also arises
> > > when installing evil from MELPA?
> >
> > On MELPA everything is smooth.
>
> Are you sure about this?  I tested myself, and the same problem occurs:
> M-x evil-mode doesn't work, although M-x describe-function evil-mode does.

Yes, I do.

> I consider this an upstream bug.  Although most users will call
> `evil-mode' in their init file, one of the reasons for using the
> package.el packaging format is that a user can just do `M-x
> package-install evil RET M-x evil-mode RET' to quickly try out a new
> mode without doing any config.
>
> Since we have fixed this bug in the Debian package, we ought to forward
> our work upstream.  Since we fixed it by some code in d/rules, we can't
> just send a patch they can apply.  So I suggest that you file an
> upstream bug report, explain what you did to fix the problem for the
> Debian package, and put a link to that bug report in the Forwarded:
> header of the patch and also as a comment in d/rules.

Can you please report upstream yourself? I can't reproduce bug via MELPA.
See:

 * If I build without my patch, the following autoload form will appear in
   evil-autoloads.el

(autoload 'evil-mode "evil")

   Note the lack of third and forth arguments, description and
   interactive markers.

 * With my patch, and before sed, we have following autoload:

(autoload 'evil-mode "evil-core" "\
Toggle Evil-Local mode in all buffers.
With prefix ARG, enable Evil mode if ARG is positive;
otherwise, disable it.  If called from Lisp, enable the mode if
ARG is omitted or nil.

Evil-Local mode is enabled in all buffers where
`evil-initialize' would do it.
See `evil-local-mode' for more information on Evil-Local mode.

\(fn &optional ARG)" t nil)

   Note that "evil-core" is autoloaded -- file where evil-mode is defined,
   but not while evil suite.

 * And here is autoload from my
   ~/.emacs.d/elpa/evil-20160227.711/evil-autoloads.el:

(autoload 'evil-mode "evil" "\
Toggle Evil-Local mode in all buffers.
With prefix ARG, enable Evil mode if ARG is positive;
otherwise, disable it.  If called from Lisp, enable the mode if
ARG is omitted or nil.

Evil-Local mode is enabled in all buffers where
`evil-initialize' would do it.
See `evil-local-mode' for more information on Evil-Local mode.

\(fn &optional ARG)" t nil)

   Everything is perfect. #'evil-mode autoloads whole evil suite.

> Another thing :)  I don't think you need to invoke find(1) in d/rules.
> You can just do something like this:
>
> sed -i 's#foo..' 
> debian/elpa-evil/usr/share/emacs/site-lisp/elpa-src/evil-*/evil-autoloads.el
>
> That's more explicit and easier to understand.

Done.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#825359: sbuild: unrealistic figure about total space used

[Johannes Schauer]

Hi,

Quoting Santiago Vila (2016-07-01 10:44:28)
> > Santiago, I noticed that you are using a directory type chroot without
> > using union-type=overlay. Could it be that your /chroot/stretch/build
> > directory contains leftovers of previous builds?
> 
> That both can't be and should not be :-)
> 
> It "can't be" because even if du is accounting for any leftover,
> in either case the reported space would never be higher than the disk
> size (I don't have such a big disk).
> 
> Also, it "should not be" because sbuild creates a temporary directory in
> /chroot/stretch/build named
> 
> /chroot/stretch/build/sourcename-randomstring
> 
> I want to believe that the "du" command is performed on this last
> directory, not on its parent, but I will leave this to you to check, since
> you know the code a lot better than me.

indeed, unless I am missing something, any invocation of 'du' in the sbuild
code base operates on the right directory, namely the one that is replaced with
<> in the build log and which takes the form of:

/build/srcpkgname-randomstring/srcpkgname-version

Thus, the directory should be unique for each build and not contain anything
from possibly parallel builds.

The only other du usage is on the files generated by sbuild, for example the
.deb packages it leaves outside the chroot. But that path also exactly points
at the .deb...

It would indeed help most if I could see the problem in one of my own machines.
But so far I'm unable to reproduce the issue.

Could you maybe:

 1. use debootstrap to create a new chroot
 2. bind-mount /dev, /proc and /sys into that
 3. chroot into the directory
 4. install sbuild
 5. run sbuild-update --keygen
 6. run sbuild-createchroot
 7. build a package

For me, following these steps lets sbuild produce the expected output. Can you
confirm this? I can also send you a sequence of command line invocations to
achieve the above if that makes things easier for you.

If you can confirm this, can you show me what the difference is between that
setup and yours?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#812284: Workaround for googletest

[Christian Hofstaedtler]

Uploaded to DELAYED/1.

Bug#796300: dbconfig-common: Write out SQL file if connection to database fails

[Christian Seiler]

Hi Paul,

On 07/01/2016 08:43 AM, Paul Gevers wrote:
> On 30-06-16 23:39, Christian Seiler wrote:
>> Does this give you an idea of what I have in mind?
> 
> Just thinking, would it make sense to enable dbconfig-common outside of
> the normal package postinst, such that it can use all the data, and just
> runs as if it was during the normal postinst? It looks like that script
> is nearly the script that you need.

I think so, yes.

> Do you object if we would just always create the script if
> configuration fails?

In certain circumstances. I don't remember exactly what happens
at the moment if you misspell the host name (because that was
too long ago that that has happened to me), but IIRC dbconfig
would either re-ask the question of fail configure, so the
admin would have a significant feedback in that case. If you
change this to just silently create the script, then admins
might not notice that configuration failed (especially if they
are installing a ton of packages at the same time).

So if you properly handle this in some way (whichever you
believe to be most appropriate), so that this change doesn't
blind-side admins that expect feedback if something goes wrong
then I'd be OK with it.

Regards,
Christian

Bug#829174: beast-mcmc: depends on package in contrib

[Andreas Tille]

Hi Jakub,

that's simply overlooked contrib section remainings for some binary
packages.  Both beast-mcmc and libnucleotidelikelihoodcore0 are build
from the same source which was moved from contrib to main but it was not
fixed in all Section fields.

Build for fixing this is just running ...

Thanks for pointing this out

 Andreas.

On Fri, Jul 01, 2016 at 10:17:51AM +0200, Jakub Wilk wrote:
> Source: beast-mcmc
> Version: 1.8.4+dfsg-1
> Severity: grave
> 
> beast-mcmc is main, but it depends on libnucleotidelikelihoodcore0, which is
> in contrib.
> 
> This is violation of Policy §2.2.1, and it makes the package uninstallable
> for users who didn't enable contrib.
> 
> -- 
> Jakub Wilk
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#812013: goffice-0.8: FTBFS with GCC 6: format not a string literal

[Robert Bihlmeyer]

Source: goffice-0.8
Followup-For: Bug #812013

For the go_format_odf_style_map() issue, the fix is simply to make the format 
string
itself constant. Patch attached.

I can't see a way to make g_object_set_property()'s error_template parameter 
safe, except
by sanity-checking in the function itself. One would probably have to turn the 
warning
off for this file...
diff -ru goffice-0.8-0.8.17/goffice/utils/go-format.c goffice-0.8-0.8.17+/goffice/utils/go-format.c
--- goffice-0.8-0.8.17/goffice/utils/go-format.c	2011-06-17 00:46:51.0 +0200
+++ goffice-0.8-0.8.17+/goffice/utils/go-format.c	2016-07-01 10:50:12.072984065 +0200
@@ -5537,7 +5537,7 @@
 char *
 go_format_odf_style_map (GOFormat const *fmt, int cond_part)
 {
-	char const *format_string = NULL;
+	char const *op = NULL;
 
 	g_return_val_if_fail (fmt != NULL, NULL);
 	g_return_val_if_fail (fmt->typ == GO_FMT_COND, NULL);
@@ -5547,29 +5547,29 @@
 
 	switch (fmt->u.cond.conditions[cond_part].op) {
 	case GO_FMT_COND_EQ:
-		format_string = "value()=%g";
+		op = "=";
 		break;
 	case GO_FMT_COND_NE:
-		format_string = "value()!=%g";
+		op = "!=";
 		break;
 	case GO_FMT_COND_NONTEXT: /* Under certain circumstances this */
   /*appears for second of two conditions */
 	case GO_FMT_COND_LT:
-		format_string = "value()<%g";
+		op = "<";
 		break;
 	case GO_FMT_COND_LE:
-		format_string = "value()<=%g";
+		op = "<=";
 		break;
 	case GO_FMT_COND_GT:
-		format_string = "value()>%g";
+		op = ">";
 		break;
 	case GO_FMT_COND_GE:
-		format_string = "value()>=%g";
+		op = ">=";
 		break;
 	default:
 		return NULL;
 	}
-	return g_strdup_printf (format_string,
+	return g_strdup_printf ("value()%s%g", op,
 fmt->u.cond.conditions[cond_part].val);
 
 }

Bug#826952: kernel-wedge: preprocess should honor KW_CHECK_NONFATAL for wildcard inclusions

[Juerg Haefliger]

> I agree that this error shouldn't be fatal in case that variable is
> set, but there should still be a warning.
> 
> Additionally, the variable test should exists() as well as length() to
> avoid a Perl warning when the variable is not defined at all.  (find-
> dups gets away with this because the embedded Perl script does not
> enable warnings.)
> 
> Ben.

How about the following?

...Juerg


diff --git a/commands/preprocess b/commands/preprocess
index 045903b..37b8e67 100755
--- a/commands/preprocess
+++ b/commands/preprocess
@@ -35,9 +35,12 @@ sub expandwildcards {
if (! -d "$moddir/$subdir") {
if (-d "$moddir/kernel/$subdir") {
$subdir = "kernel/$subdir";
-   } elsif ($checkdir) {
-   die "pattern $pattern refers to nonexistent 
subdirectory";
} else {
+   if ($checkdir) {
+   print STDERR "missing module directory 
$pattern\n";
+   die if 
!(exists($ENV{KW_CHECK_NONFATAL}) &&
+
length($ENV{KW_CHECK_NONFATAL}));
+   }
return ();
}
}




signature.asc
Description: OpenPGP digital signature

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Dmitry Bogatov]

> > > Thanks for your response.  I think this package is almost ready.  Please
> > > add Forwarded: headers to the patches based on our discussion.
> > Is it any wat to get best of 'gbp pq' and dep3?
> I generally resort to using quilt :(

Added Forwarded: header at bootom of description. It works. If I add it at top,
it will be lost during patch->commit->patch conversion.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#815304: Converted package available

[Sean Whitton]

Dear maintainer,

For your convenience I have prepared a conversion (no intention to
upload without your agreement):

git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/s-el

-- 
Sean Whitton

Bug#829142: debhelper: dh_strip triggers fatal lintian error for packages with multiple hardlinks

[Sven Joachim]

On 2016-07-01 00:05 +0200, Sven Joachim wrote:

> Package: debhelper
> Version: 9.20160618.1
> Severity: serious
>
> For packages which ship files with multiple hardlinks, dh_strip produces
> broken -dbgsym packages that trigger the
> library-in-debug-or-profile-should-not-be-stripped lintian error, which
> unfortunately leads to auto-rejection by the FTP masters and cannot be
> overridden.

The culprit is commit d98cb4705e ("dh_strip: Cache file(1) output").
Prior to this commit, dh_strip would detect that the file had already
been stripped, but now it strips it multiple times, producing unusable
debug info.

For packages which ship automatic debug symbols or use debhelper compat
level ≥ 9, the following patch works:

--8<---cut here---start->8---
diff --git a/dh_strip b/dh_strip
index 8d00e97..7d40c24 100755
--- a/dh_strip
+++ b/dh_strip
@@ -276,7 +276,8 @@ sub make_debug {
}
else {
# Compat 9 OR a dbgsym package.
-   doit($objcopy, "--only-keep-debug", 
"--compress-debug-sections", $file, $debug_path);
+   doit($objcopy, "--only-keep-debug", 
"--compress-debug-sections", $file, $debug_path)
+   unless -e $debug_path;
}
 
# No reason for this to be executable.
--8<---cut here---end--->8---

However, this does not help in the case of manual -dbg packages and
debhelper compat level ≤ 8, since $debug_path is then different for
different hardlinks to the same file.

Cheers,
   Sven

Bug#829184: mnormt: FTBFS: dh_clean: Please specify the compatibility level in debian/compat

[Chris Lamb]

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

Dear Maintainer,

mnormt fails to build from source in unstable/amd64:

  [..]

  Preparing to unpack .../x11-common_1%3a7.7+15_all.deb ...
  Unpacking x11-common (1:7.7+15) ...
  Selecting previously unselected package libice6:amd64.
  Preparing to unpack .../libice6_2%3a1.0.9-1+b1_amd64.deb ...
  Unpacking libice6:amd64 (2:1.0.9-1+b1) ...
  Selecting previously unselected package libjpeg62-turbo:amd64.
  Preparing to unpack .../libjpeg62-turbo_1%3a1.5.0-1_amd64.deb ...
  Unpacking libjpeg62-turbo:amd64 (1:1.5.0-1) ...
  Selecting previously unselected package liblapack3.
  Preparing to unpack .../liblapack3_3.6.1-1_amd64.deb ...
  Unpacking liblapack3 (3.6.1-1) ...
  Selecting previously unselected package fontconfig.
  Preparing to unpack .../fontconfig_2.11.0-6.4_amd64.deb ...
  Unpacking fontconfig (2.11.0-6.4) ...
  Selecting previously unselected package libthai-data.
  Preparing to unpack .../libthai-data_0.1.25-1_all.deb ...
  Unpacking libthai-data (0.1.25-1) ...
  Selecting previously unselected package libdatrie1:amd64.
  Preparing to unpack .../libdatrie1_0.2.10-2_amd64.deb ...
  Unpacking libdatrie1:amd64 (0.2.10-2) ...
  Selecting previously unselected package libthai0:amd64.
  Preparing to unpack .../libthai0_0.1.25-1_amd64.deb ...
  Unpacking libthai0:amd64 (0.1.25-1) ...
  Selecting previously unselected package libpango-1.0-0:amd64.
  Preparing to unpack .../libpango-1.0-0_1.40.1-1_amd64.deb ...
  Unpacking libpango-1.0-0:amd64 (1.40.1-1) ...
  Selecting previously unselected package libgraphite2-3:amd64.
  Preparing to unpack .../libgraphite2-3_1.3.8-1_amd64.deb ...
  Unpacking libgraphite2-3:amd64 (1.3.8-1) ...
  Selecting previously unselected package libharfbuzz0b:amd64.
  Preparing to unpack .../libharfbuzz0b_1.2.6-2_amd64.deb ...
  Unpacking libharfbuzz0b:amd64 (1.2.6-2) ...
  Selecting previously unselected package libpangoft2-1.0-0:amd64.
  Preparing to unpack .../libpangoft2-1.0-0_1.40.1-1_amd64.deb ...
  Unpacking libpangoft2-1.0-0:amd64 (1.40.1-1) ...
  Selecting previously unselected package libpangocairo-1.0-0:amd64.
  Preparing to unpack .../libpangocairo-1.0-0_1.40.1-1_amd64.deb ...
  Unpacking libpangocairo-1.0-0:amd64 (1.40.1-1) ...
  Selecting previously unselected package libsm6:amd64.
  Preparing to unpack .../libsm6_2%3a1.2.2-1+b1_amd64.deb ...
  Unpacking libsm6:amd64 (2:1.2.2-1+b1) ...
  Selecting previously unselected package libtcl8.6:amd64.
  Preparing to unpack .../libtcl8.6_8.6.5+dfsg-2_amd64.deb ...
  Unpacking libtcl8.6:amd64 (8.6.5+dfsg-2) ...
  Selecting previously unselected package libjbig0:amd64.
  Preparing to unpack .../libjbig0_2.1-3.1_amd64.deb ...
  Unpacking libjbig0:amd64 (2.1-3.1) ...
  Selecting previously unselected package libtiff5:amd64.
  Preparing to unpack .../libtiff5_4.0.6-1_amd64.deb ...
  Unpacking libtiff5:amd64 (4.0.6-1) ...
  Selecting previously unselected package libxft2:amd64.
  Preparing to unpack .../libxft2_2.3.2-1_amd64.deb ...
  Unpacking libxft2:amd64 (2.3.2-1) ...
  Selecting previously unselected package libxss1:amd64.
  Preparing to unpack .../libxss1_1%3a1.2.2-1_amd64.deb ...
  Unpacking libxss1:amd64 (1:1.2.2-1) ...
  Selecting previously unselected package libtk8.6:amd64.
  Preparing to unpack .../libtk8.6_8.6.5-1_amd64.deb ...
  Unpacking libtk8.6:amd64 (8.6.5-1) ...
  Selecting previously unselected package libxt6:amd64.
  Preparing to unpack .../libxt6_1%3a1.1.5-1_amd64.deb ...
  Unpacking libxt6:amd64 (1:1.1.5-1) ...
  Selecting previously unselected package openssl.
  Preparing to unpack .../openssl_1.0.2h-1_amd64.deb ...
  Unpacking openssl (1.0.2h-1) ...
  Selecting previously unselected package ca-certificates.
  Preparing to unpack .../ca-certificates_20160104_all.deb ...
  Unpacking ca-certificates (20160104) ...
  Selecting previously unselected package r-base-core.
  Preparing to unpack .../r-base-core_3.3.1-1_amd64.deb ...
  Unpacking r-base-core (3.3.1-1) ...
  Selecting previously unselected package libgfortran-5-dev:amd64.
  Preparing to unpack .../libgfortran-5-dev_5.4.0-5_amd64.deb ...
  Unpacking libgfortran-5-dev:amd64 (5.4.0-5) ...
  Selecting previously unselected package gfortran-5.
  Preparing to unpack .../gfortran-5_5.4.0-5_amd64.deb ...
  Unpacking gfortran-5 (5.4.0-5) ...
  Selecting previously unselected package gfortran.
  Preparing to unpack .../gfortran_4%3a5.3.1-3_amd64.deb ...
  Unpacking gfortran (4:5.3.1-3) ...
  Selecting previously unselected package libblas-dev.
  Preparing to unpack .../libblas-dev_3.6.1-1_amd64.deb ...
  Unpacking libblas-dev (3.6.1-1) ...
  Selecting previously unselected package liblapack-dev.
  Preparing to unpack .../liblapack-dev_3.6.1-1_amd64.deb ...
  Unpacking liblapack-dev (3.6.1-1) ...
  Selecting previously unselected package libtinfo-d

Bug#829185: ITP: gnome-shell-extension-dashtodock -- dash-to-dock extension for GNOME shell

[Jonathan Carter]

Package: wnpp
Severity: wishlist
Owner: Jonathan Carter 

* Package name: gnome-shell-extension-dashtodock
  Version : 53
  Upstream Author : Michele 
* URL : https://micheleg.github.io/dash-to-dock/
* License : GPL-2+
  Programming Lang: JavaScript
  Description : dash-to-dock extension for GNOME shell

Dash to dock extension is an enhanced dash for GNOME Shell. It moves the
default dash out of the overview and transforms it in a dock for an easier
launching of applications and a faster switching between windows and
workspaces without leaving the desktop view improving the workflow in your
system.
.
It supports autohide and intellihide modes as well as a fixed mode.
Optional features are available in the extension settings. The extension
is themes friendly.

Bug#829147: tidy-html5: Please drop unnecessary dependency on libdmalloc-dev

[Daniel James]

Hi Steve, hi Gianfranco

This change has been applied in:

http://anonscm.debian.org/cgit/collab-maint/tidy-html5.git/commit/?id=819ecee3f62ef8093c36082205f687b2a728b245

I have several other fixes to make, so a new package should be available
shortly.

Cheers!

Daniel

Bug#829186: ganeti: FTBFS in testing (role 'manpage' is already registered)

[Santiago Vila]

Package: src:ganeti
Version: 2.15.2-3
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
dir=doc/html/ && \
/bin/mkdir -p $dir && \
PYTHONPATH=. ENABLE_MANPAGES= COPY_DOC=1 \
HTML_THEME=classic \
./autotools/run-in-tempdir autotools/sphinx-wrapper /usr/bin/sphinx-build -q -W 
-b html \
-d . \
-D version="2.15" \
-D release="2.15.2" \
-D graphviz_dot="/usr/bin/dot" \
doc /<>/$dir && \
rm -f $dir/.buildinfo $dir/objects.inv

Warning, treated as error:
WARNING: while setting up extension ganeti.build.sphinx_ext: role 'manpage' is 
already registered, it will be
 overridden

Makefile:4283: recipe for target 'doc/html/index.html' failed
make[2]: *** [doc/html/index.html] Error 1
make[2]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
debian/rules:82: recipe for target 'override_dh_auto_build' failed


A full build log is available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/ganeti_2.15.2-3.rbuild.log

Thanks.

Bug#829187: perforate: FTBFS: dh_clean: Please specify the compatibility level in debian/compat

[Chris Lamb]

Source: perforate
Version: 1.2-5
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

perforate fails to build from source in unstable/amd64:

  [..]

  
  
**
  ** Starting build 
  **
  
**
  
   Package:  perforate
   Version:  1.2-5
   Build architecture:   amd64
   Date: Fri, 01 Jul 2016 11:30:42 +0200
   Hostname: 6f8cdc9995f0
   Uname:Linux 6f8cdc9995f0 4.6.0-1-amd64 #1 SMP Debian 4.6.2-2 
(2016-06-25) x86_64 GNU/Linux
   /etc/timezone:Africa/Johannesburg
  
  
**
  ** Installing build dependencies  
  **
  
**
  
  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'perforate-build-deps' in 
'../perforate-build-deps_1.2-5_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package perforate-build-deps.
  (Reading database ... 23081 files and directories currently installed.)
  Preparing to unpack perforate-build-deps_1.2-5_all.deb ...
  Unpacking perforate-build-deps (1.2-5) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  After this operation, 0 B of additional disk space will be used.
  Setting up perforate-build-deps (1.2-5) ...
  
  
**
  ** Environment
  **
  
**
  
  
PATH=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  HOSTNAME=6f8cdc9995f0
  TERM=xterm
  PAGER=more
  DISPLAY=:0
  DOCKER_IMAGE=lamby-debian-sid
  DEB_BUILD_OPTIONS=parallel=9
  PIP_DOWNLOAD_CACHE=/home/lamby/.cache/pip
  HOME=/home/lamby
  LOGNAME=lamby
  SHLVL=1
  PWD=/home/lamby/temp/cdt.20160701113040.s2qetV6vlu.perforate/perforate-1.2
  OLDPWD=/home/lamby/temp/cdt.20160701113040.s2qetV6vlu.perforate
  GPG_TTY=/dev/console
  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**
  ** Building perforate 1.2-5 on amd64  
  **
  
**
  
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package perforate
  dpkg-buildpackage: info: source version 1.2-5
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Hector Garcia 
   dpkg-source --before-build perforate-1.2
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  dh_testdir
  dh_testroot
  dh_clean build.stamp zum
  dh_clean: Please specify the compatibility level in debian/compat
  debian/rules:14: recipe for target 'clean' failed
  make: *** [clean] Error 2

  [..]

The full build log is attached.


Regards,

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


perforate.1.2-5.unstable.amd64.log.txt.gz
Description: Binary data

Bug#826952: kernel-wedge: preprocess should honor KW_CHECK_NONFATAL for wildcard inclusions

[Ben Hutchings]

On Fri, 2016-07-01 at 11:02 +0200, Juerg Haefliger wrote:
> > 
> > I agree that this error shouldn't be fatal in case that variable is
> > set, but there should still be a warning.
> > 
> > Additionally, the variable test should exists() as well as length() to
> > avoid a Perl warning when the variable is not defined at all.  (find-
> > dups gets away with this because the embedded Perl script does not
> > enable warnings.)
> > 
> > Ben.
> 
> How about the following?
> 
> ...Juerg
> 
> 
> diff --git a/commands/preprocess b/commands/preprocess
> index 045903b..37b8e67 100755
> --- a/commands/preprocess
> +++ b/commands/preprocess
> @@ -35,9 +35,12 @@ sub expandwildcards {
> if (! -d "$moddir/$subdir") {
> if (-d "$moddir/kernel/$subdir") {
> $subdir = "kernel/$subdir";
> -   } elsif ($checkdir) {
> -   die "pattern $pattern refers to nonexistent 
> subdirectory";
> } else {
> +   if ($checkdir) {
> +   print STDERR "missing module 
> directory $pattern\n";

The directory is $subdir not $pattern.

Aside from that, I think this is good.

Ben.

> +   die if 
> !(exists($ENV{KW_CHECK_NONFATAL}) &&
> +
> length($ENV{KW_CHECK_NONFATAL}));
> +   }
> return ();
> }
> }
> 
> 
-- 

Ben Hutchings
All extremists should be taken out and shot.


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

Bug#829188: SEGVs too frequently (~every other day)

[Matthew Vernon]

Package: icedove
Version: 1:45.1.0-1
Severity: serious

Hi,

The most recent icedove is far too unstable; it SEGVs fairly frequently. 
I run it on my workstation at work, starting it afresh in the morning 
and closing it when I leave work. I estimate I'm seeing a SEGV about 
every other work-day. This is unacceptably unstable, and much worse than 
previous versions.

I'm afraid I don't get much of use other than a SEGV, and it's not 
guaranteed to happen at any given point (though heavy IMAP traffic seems 
more likely to make it happen).

I appreciate this is a rather unhelpful report, but this version of 
icedove is really too crashy.

Regards,

Matthew

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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: sysvinit (via /sbin/init)

Versions of packages icedove depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.4
ii  libasound21.1.1-2
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.22-11
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-7
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libglib2.0-0  2.48.1-1
ii  libgtk2.0-0   2.24.30-2
ii  libhunspell-1.4-0 1.4.1-2
ii  libicu55  55.1-7
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.23-2
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpixman-1-0 0.33.6-1
ii  libsqlite3-0  3.13.0-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-7
ii  libvpx3   1.5.0-3
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-gb [hunspell-dictionary]  1:5.1.3-2
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.1.0-1

Versions of packages icedove suggests:
ii  fonts-lyx 2.2.0-1
ii  libgssapi-krb5-2  1.14.2+dfsg-1

-- no debconf information

Bug#829189: pyqi: FTBFS: dpkg-query: no path found matching pattern /usr/share/sphinx/themes/basic/static/doctools.jsdh_linktree: error: dpkg --search -- /usr/share/sphinx/themes/basic/static/doctools

[Chris Lamb]

Source: pyqi
Version: 0.3.2+dfsg-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

pyqi fails to build from source in unstable/amd64:

  [..]

  update-alternatives: using /usr/share/docutils/scripts/python2/rst2xetex to 
provide /usr/bin/rst2xetex (rst2xetex) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rst2xml to 
provide /usr/bin/rst2xml (rst2xml) in auto mode
  update-alternatives: using /usr/share/docutils/scripts/python2/rstpep2html to 
provide /usr/bin/rstpep2html (rstpep2html) in auto mode
  Setting up python-sphinx (1.4.4-2) ...
  Setting up pyqi-build-deps (0.3.2+dfsg-1) ...
  
  
**
  ** Environment
  **
  
**
  
  
PATH=/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  HOSTNAME=72c260519895
  TERM=xterm
  PAGER=more
  DISPLAY=:0
  DOCKER_IMAGE=lamby-debian-sid
  DEB_BUILD_OPTIONS=parallel=9
  PIP_DOWNLOAD_CACHE=/home/lamby/.cache/pip
  HOME=/home/lamby
  LOGNAME=lamby
  SHLVL=1
  PWD=/home/lamby/temp/cdt.20160701114659.5zbWEeRWgf.pyqi/pyqi-0.3.2+dfsg
  OLDPWD=/home/lamby/temp/cdt.20160701114659.5zbWEeRWgf.pyqi
  GPG_TTY=/dev/console
  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**
  ** Building pyqi 0.3.2+dfsg-1 on amd64
  **
  
**
  
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package pyqi
  dpkg-buildpackage: info: source version 0.3.2+dfsg-1
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Andreas Tille 
   dpkg-source --before-build pyqi-0.3.2+dfsg
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  dh  clean --with python2 --with linktree
 dh_testdir
 debian/rules override_dh_auto_clean
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160701114659.5zbWEeRWgf.pyqi/pyqi-0.3.2+dfsg'
  dh_auto_clean
  pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
  pyversions: missing debian/pyversions file, fall back to supported versions
python setup.py clean -a
  running clean
  'build/lib.linux-x86_64-2.7' does not exist -- can't clean it
  'build/bdist.linux-x86_64' does not exist -- can't clean it
  'build/scripts-2.7' does not exist -- can't clean it
find . -name \*.pyc -exec rm {} \+
  cd doc && make clean
  make[2]: Entering directory 
'/home/lamby/temp/cdt.20160701114659.5zbWEeRWgf.pyqi/pyqi-0.3.2+dfsg/doc'
  rm -rf _build/*
  make[2]: Leaving directory 
'/home/lamby/temp/cdt.20160701114659.5zbWEeRWgf.pyqi/pyqi-0.3.2+dfsg/doc'
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160701114659.5zbWEeRWgf.pyqi/pyqi-0.3.2+dfsg'
 dh_clean
   debian/rules build
  dh  build --with python2 --with linktree
 dh_testdir
 dh_update_autotools_config
 dh_auto_configure
 debian/rules override_dh_auto_build
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160701114659.5zbWEeRWgf.pyqi/pyqi-0.3.2+dfsg'
  dh_auto_build
  pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
  pyversions: missing debian/pyversions file, fall back to supported versions
python setup.py build --force
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-2.7
  creating build/lib.linux-x86_64-2.7/pyqi
  copying pyqi/functional.py -> build/lib.linux-x86_64-2.7/pyqi
  copying pyqi/__init__.py -> build/lib.linux-x86_64-2.7/pyqi
  copying pyqi/util.py -> build/lib.linux-x86_64-2.7/pyqi
  creating build/lib.linux-x86_64-2.7/pyqi/commands
  copying pyqi/commands/serve_html_interface.py -> 
build/lib.linux-x86_64-2.7/pyqi/commands
  copying pyqi/commands/make_bash_completion.py -> 
build/lib.linux-x86_64-2.7/pyqi/commands
  copying pyqi/commands/__init__.py -> build/lib.linux-x86_64-2.7/pyqi/commands
  copying pyqi/commands/make_command.py -> 
build/lib.linux-x86_64-2.7/pyqi/commands
  copying pyqi/commands/code_header_generator.py -> 
build/lib.linux-x86_64-2.7/pyqi/commands
  copying pyqi/commands/make_optparse.py -> 
build/lib.linux-x86_64-2.7/pyqi/commands
  copying pyqi/commands/make_release.py -> 
build/lib.linux-x86_64-2.7/pyqi/commands
  creating build/lib.linux-x86_64

Bug#829190: /usr/share/texlive/texmf-dist/scripts/texlive/tlmgr.pl: tlmgr install fails: Unknown directive ...containerchecksum ...

[Johannes Ranke]

Package: texlive-base
Version: 2014.20141024-2
Severity: normal
File: /usr/share/texlive/texmf-dist/scripts/texlive/tlmgr.pl

Dear Maintainer,

I would like to install the most recent version of the metropolis
package on Debian stable. So I did

  tlmgr init-usertree

which created a fresh user tree under ~/texmf, but then

  tlmgr install metropolis

gives me

  (running on Debian, switching to user mode!)
  Unknown directive ...containerchecksum
  
c59200574a316416a23695c258edf3a32531fbda43ccdc09360ee105c3f07f9fb77df17c4ba4c2ea4f3a5ea6667e064b51e3d8c2fe6c984ba3e71b4e32716955...
  , please fix it! at /usr/share/texlive/tlpkg/TeXLive/TLPOBJ.pm line
  210, <$retfh> line 5579.

I had a look at the file TLPOBJ.pm but am not able to see what is going
wrong.

Thanks,

Johannes

##
 List of ls-R files

-rw-r--r-- 1 jranke jranke 599 Feb  4  2015 /home/jranke/texmf/ls-R
-rw-r--r-- 1 root root 1251 Jun 24 12:38 /var/lib/texmf/ls-R
-rw-rw-r-- 1 jranke staff 80 Mar 24  2015 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 21  2014 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Dec  2  2014 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Dec  2  2014 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 945 Nov 13  2015 /etc/texmf/web2c/texmf.cnf
-rw-r--r-- 1 root root 4897 Jun 24 12:38 /var/lib/texmf/web2c/fmtutil.cnf
lrwxrwxrwx 1 root root 32 Dec  2  2014 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 4429 Jun 24 12:38 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Oct 21  2014 mktex.cnf
-rw-r--r-- 1 root root 945 Nov 13  2015 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf
1df66bc319cec731e202eaf39f5d85e1  /etc/texmf/texmf.d/96JadeTeX.cnf
c95cb926cc5d0b758ade26598679a2a1  /etc/texmf/texmf.d/local.cnf

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

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

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  libpaper-utils 1.1.24+nmu4
ii  tex-common 5.03
ii  texlive-binaries   2014.20140926.35254-6
ii  ucf3.0030
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

Versions of packages texlive-base recommends:
ii  lmodern  2.004.4-5

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   3.14.1-2+deb8u1
ii  ghostscript [postscript-viewer]  9.06~dfsg-2+deb8u1
ii  okular [postscript-viewer]   4:4.14.2-2
pn  perl-tk  
ii  xpdf [pdf-viewer]3.03-17+b1

Versions of packages tex-common depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  ucf3.0030

Versions of packages tex-common suggests:
ii  debhelper  9.20150101

Versions of packages texlive-base is related to:
ii  tex-common5.03
ii  texlive-binaries  2014.20140926.35254-6

-- debconf information excluded

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[Gianfranco Costamagna]

Hi Jose, do you have any ETA for this issue?

this is preventing the opencv decruft, and the transition in Ubuntu.

thanks

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#829191: python-pydot-ng: FTBFS: pydot_ng/__init__.py:1958: InvocationException

[Chris Lamb]

Source: python-pydot-ng
Version: 1.0.0-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-pydot-ng fails to build from source in unstable/amd64:

  [..]

  pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
  pyversions: missing debian/pyversions file, fall back to supported versions
  py3versions: no X-Python3-Version in control file, using supported versions
  dh_clean -O--buildsystem=python_distutils
  rm -rf build
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160701115412.iR2SLMJMIF.python-pydot-ng/python-pydot-ng-1.0.0'
   debian/rules build
  pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
  pyversions: missing debian/pyversions file, fall back to supported versions
  pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
  pyversions: missing debian/pyversions file, fall back to supported versions
  py3versions: no X-Python3-Version in control file, using supported versions
  dh build --buildsystem=python_distutils --with python2
 dh_testdir -O--buildsystem=python_distutils
 dh_update_autotools_config -O--buildsystem=python_distutils
 dh_auto_configure -O--buildsystem=python_distutils
 dh_auto_build -O--buildsystem=python_distutils
  pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
  pyversions: missing debian/pyversions file, fall back to supported versions
python setup.py build --force
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-2.7
  creating build/lib.linux-x86_64-2.7/pydot_ng
  copying pydot_ng/__init__.py -> build/lib.linux-x86_64-2.7/pydot_ng
  copying pydot_ng/_dotparser.py -> build/lib.linux-x86_64-2.7/pydot_ng
 debian/rules override_dh_auto_test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160701115412.iR2SLMJMIF.python-pydot-ng/python-pydot-ng-1.0.0'
  pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
  pyversions: missing debian/pyversions file, fall back to supported versions
  pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
  pyversions: missing debian/pyversions file, fall back to supported versions
  py3versions: no X-Python3-Version in control file, using supported versions
  set -e ; for pyvers in 2.7 3.5; do \
python$pyvers -m pytest test ; \
  done
  = test session starts 
==
  platform linux2 -- Python 2.7.12, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
  rootdir: 
/home/lamby/temp/cdt.20160701115412.iR2SLMJMIF.python-pydot-ng/python-pydot-ng-1.0.0,
 inifile: 
  collected 23 items
  
  test/test_pydot.py ss.FF..
  
  === FAILURES 
===
   TestGraphAPI.test_my_regression_tests 
_
  
  self = 
  
  def test_my_regression_tests(self):
  >   self._render_and_compare_dot_files(MY_REGRESSION_TESTS_DIR)
  
  test/test_pydot.py:222: 
  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ 
  test/test_pydot.py:243: in _render_and_compare_dot_files
  parsed_data_hexdigest = self._render_with_pydot(fname)
  test/test_pydot.py:217: in _render_with_pydot
  jpe_data = NULL_SEP.join([_g.create(format='jpe') for _g in g])
  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ 
  
  self = , prog = 'dot', format = 'jpe'
  
  def create(self, prog=None, format='ps'):
  """Creates and returns a Postscript representation of the graph.
  
  create will write the graph to a temporary dot file and process
  it with the program given by 'prog' (which defaults to 'twopi'),
  reading the Postscript output and returning it as a string is the
  operation is successful.
  On failure None is returned.
  
  There's also the preferred possibility of using:
  
  create_'format'(prog='program')
  
  which are automatically defined for all the supported formats.
  [create_ps(), create_gif(), create_dia(), ...]
  
  If 'prog' is a list instead of a string the fist item is expected
  to be the program name, followed by any optional command-line
  arguments for it:
  
  ['twopi', '-Tdot', '-s10']
  """
  
  if prog is None:
  prog = self.prog
  
  if isinstance(prog, (list, tuple)):
  prog, args = prog[0], prog[1:]
  else:
  args = []
  
  if self.progs is None:
  self.progs = find_graphviz()

Bug#829192: python-requests-toolbelt: FTBFS: sphinx_rtd_theme is no longer a hard dependency since version 1.4.0

[Chris Lamb]

Source: python-requests-toolbelt
Version: 0.6.0-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-requests-toolbelt fails to build from source in unstable/amd64:

  [..]

  running egg_info
  writing requirements to requests_toolbelt.egg-info/requires.txt
  writing requests_toolbelt.egg-info/PKG-INFO
  writing top-level names to requests_toolbelt.egg-info/top_level.txt
  writing dependency_links to requests_toolbelt.egg-info/dependency_links.txt
  reading manifest file 'requests_toolbelt.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  no previously-included directories found matching 'docs/_build'
  warning: no previously-included files matching '*.py[cdo]' found anywhere in 
distribution
  warning: no previously-included files matching '__pycache__' found anywhere 
in distribution
  warning: no previously-included files matching '*.so' found anywhere in 
distribution
  warning: no previously-included files matching '*.pyd' found anywhere in 
distribution
  writing manifest file 'requests_toolbelt.egg-info/SOURCES.txt'
  creating 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_2.7/build/requests_toolbelt/cookies
  copying requests_toolbelt/cookies/__init__.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_2.7/build/requests_toolbelt/cookies
  copying requests_toolbelt/cookies/forgetful.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_2.7/build/requests_toolbelt/cookies
pybuild --build -i python{version} -p 3.5
  I: pybuild base:184: /usr/bin/python3 setup.py build 
  running build
  running build_py
  creating 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt
  copying requests_toolbelt/__init__.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt
  copying requests_toolbelt/_compat.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt
  copying requests_toolbelt/streaming_iterator.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt
  copying requests_toolbelt/exceptions.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt
  creating 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/adapters
  copying requests_toolbelt/adapters/__init__.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/adapters
  copying requests_toolbelt/adapters/appengine.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/adapters
  copying requests_toolbelt/adapters/source.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/adapters
  copying requests_toolbelt/adapters/socket_options.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/adapters
  copying requests_toolbelt/adapters/fingerprint.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/adapters
  copying requests_toolbelt/adapters/ssl.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/adapters
  creating 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/auth
  copying requests_toolbelt/auth/__init__.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/auth
  copying requests_toolbelt/auth/handler.py -> 
/home/lamby/temp/cdt.20160701115653.NJpUwenUVV.python-requests-toolbelt/python-requests-toolbelt-0.6.0/.pybuild/pythonX.Y_3.5/build/requests_toolbelt/auth
  copying requests_toolbelt/auth/guess.py -> 
/home/lamby/temp/cdt.20160701115653.N

Bug#829194: ruby-kramdown-rfc2629: FTBFS: Could not find 'kramdown' (~> 1.10.0) - did find: [kramdown-1.11.1] (Gem::LoadError)

[Chris Lamb]

Source: ruby-kramdown-rfc2629
Version: 1.0.30-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ruby-kramdown-rfc2629 fails to build from source in unstable/amd64:

  [..]

  Get:8 http://httpredir.debian.org/debian sid/main amd64 ruby-test-unit all 
3.1.7-2 [69.6 kB]
  Get:9 http://httpredir.debian.org/debian sid/main amd64 libyaml-0-2 amd64 
0.1.6-3 [50.4 kB]
  Get:10 http://httpredir.debian.org/debian sid/main amd64 libruby2.3 amd64 
2.3.1-5 [3093 kB]
  Get:11 http://httpredir.debian.org/debian sid/main amd64 ruby2.3 amd64 
2.3.1-5 [178 kB]
  Get:12 http://httpredir.debian.org/debian sid/main amd64 ruby amd64 1:2.3.0+4 
[10.5 kB]
  Get:13 http://httpredir.debian.org/debian sid/main amd64 rake all 10.5.0-2 
[49.4 kB]
  Get:14 http://httpredir.debian.org/debian sid/main amd64 gem2deb-test-runner 
amd64 0.30.3 [19.7 kB]
  Get:15 http://httpredir.debian.org/debian sid/main amd64 libgmpxx4ldbl amd64 
2:6.1.1+dfsg-1 [22.3 kB]
  Get:16 http://httpredir.debian.org/debian sid/main amd64 libgmp-dev amd64 
2:6.1.1+dfsg-1 [629 kB]
  Get:17 http://httpredir.debian.org/debian sid/main amd64 ruby2.3-dev amd64 
2.3.1-5 [1170 kB]
  Get:18 http://httpredir.debian.org/debian sid/main amd64 ruby-all-dev amd64 
1:2.3.0+4 [9996 B]
  Get:19 http://httpredir.debian.org/debian sid/main amd64 ruby-setup all 
3.4.1-9 [34.2 kB]
  Get:20 http://httpredir.debian.org/debian sid/main amd64 gem2deb amd64 0.30.3 
[55.6 kB]
  Get:21 http://httpredir.debian.org/debian sid/main amd64 libjs-jquery all 
1.12.4-1 [167 kB]
  Get:22 http://httpredir.debian.org/debian sid/main amd64 ruby-coderay all 
1.1.1-1 [76.2 kB]
  Get:23 http://httpredir.debian.org/debian sid/main amd64 ruby-afm all 0.2.2-1 
[5506 B]
  Get:24 http://httpredir.debian.org/debian sid/main amd64 ruby-ascii85 all 
1.0.2-3 [9328 B]
  Get:25 http://httpredir.debian.org/debian sid/main amd64 ruby-hashery all 
2.1.2-1 [32.8 kB]
  Get:26 http://httpredir.debian.org/debian sid/main amd64 ruby-rc4 all 0.1.5-3 
[3992 B]
  Get:27 http://httpredir.debian.org/debian sid/main amd64 ruby-ttfunk all 
1.4.0-1 [24.0 kB]
  Get:28 http://httpredir.debian.org/debian sid/main amd64 ruby-pdf-reader all 
1.4.0-1 [129 kB]
  Get:29 http://httpredir.debian.org/debian sid/main amd64 ruby-pdf-core all 
0.6.1-1 [18.2 kB]
  Get:30 http://httpredir.debian.org/debian sid/main amd64 ruby-prawn all 
2.1.0+dfsg-1 [456 kB]
  Get:31 http://httpredir.debian.org/debian sid/main amd64 ruby-prawn-table all 
0.2.2-1 [98.2 kB]
  Get:32 http://httpredir.debian.org/debian sid/main amd64 ruby-rouge all 
1.11.0-1 [174 kB]
  Get:33 http://httpredir.debian.org/debian sid/main amd64 ruby-stringex all 
2.6.0-1 [80.6 kB]
  Get:34 http://httpredir.debian.org/debian sid/main amd64 ruby-kramdown all 
1.11.1-2 [248 kB]
  Fetched 7881 kB in 0s (53.9 MB/s)
  Selecting previously unselected package openssl.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 23085 files and directories currently installed.)
  Preparing to unpack .../openssl_1.0.2h-1_amd64.deb ...
  Unpacking openssl (1.0.2h-1) ...
  Selecting previously unselected package ca-certificates.
  Preparing to unpack .../ca-certificates_20160104_all.deb ...
  Unpacking ca-certificates (20160104) ...
  Selecting previously unselected package rubygems-integration.
  Preparing to unpack .../rubygems-integration_1.10_all.deb ...
  Unpacking rubygems-integration (1.10) ...
  Selecting previously unselected package ruby-did-you-mean.
  Preparing to unpack .../ruby-did-you-mean_1.0.0-2_all.deb ...
  Unpacking ruby-did-you-mean (1.0.0-2) ...
  Selecting previously unselected package ruby-minitest.
  Preparing to unpack .../ruby-minitest_5.9.0-1_all.deb ...
  Unpacking ruby-minitest (5.9.0-1) ...
  Selecting previously unselected package ruby-net-telnet.
  Preparing to unpack .../ruby-net-telnet_0.1.1-2_all.deb ...
  Unpacking ruby-net-telnet (0.1.1-2) ...
  Selecting previously unselected package ruby-power-assert.
  Preparing to unpack .../ruby-power-assert_0.3.0-1_all.deb ...
  Unpacking ruby-power-assert (0.3.0-1) ...
  Selecting previously unselected package ruby-test-unit.
  Preparing to unpack .../ruby-test-unit_3.1.7-2_all.deb ...
  Unpacking ruby-test-unit (3.1.7-2) ...
  Selecting previously unselected package libyaml-0-2:amd64.
  Preparing to unpack .../libyaml-0-2_0.1.6-3_amd64.deb ...
  Unpacking libyaml-0-2:amd64

Bug#829193: rsync: "/etc/init.d/rsync stop" should ensure the process has stopped before returning

[Chris Lamb]

Source: rsync
Version: 3.1.1-3
Tags: patch
User: la...@debian.org
Usertags: initscript-stop-action

Hi,

rsync's initscript does not check whether the rsync process has actually 
terminated before returning successfully.

This can result in a non-deterministic race condition where resources that are 
required by the corresponding "start" action (eg. TCP ports, exclusive 
filesystem locks, etc.) are not yet available to the new instance because the 
older process is still releasing them in the background.

This then results in the new process failing to start which is often hidden 
from the sysadmin unless a monitoring system is in use.

For the same/parallel reasons, the stop and restart actions should return a 
non-zero exit code if the daemon failed to stop. Note that adding "sleep" calls 
merely masks the problem and is not a valid fix.

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/init.d b/debian/init.d
index 3bf5167..3cb0447 100644
--- a/debian/init.d
+++ b/debian/init.d
@@ -111,8 +111,13 @@ case "$1" in
;;
   stop)
log_daemon_msg "Stopping rsync daemon" "rsync"
-   start-stop-daemon --stop --quiet --oknodo --pidfile $RSYNC_PID_FILE
-   log_end_msg $?
+   start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile 
$RSYNC_PID_FILE
+   RETVAL="$?"
+   log_end_msg $RETVAL
+   if [ $RETVAL != 0 ]
+   then
+   exit 1
+   fi
rm -f $RSYNC_PID_FILE
;;
 
@@ -126,8 +131,7 @@ case "$1" in
if $RSYNC_ENABLE; then
log_daemon_msg "Restarting rsync daemon" "rsync"
if [ -s $RSYNC_PID_FILE ] && kill -0 $(cat $RSYNC_PID_FILE) 
>/dev/null 2>&1; then
-   start-stop-daemon --stop --quiet --oknodo --pidfile 
$RSYNC_PID_FILE || true
-   sleep 1
+   start-stop-daemon --stop --quiet --oknodo --retry 30 --pidfile 
$RSYNC_PID_FILE
else
log_warning_msg "rsync daemon not running, attempting to start."
rm -f $RSYNC_PID_FILE

Bug#829195: ruby-moneta: FTBFS: /usr/lib/ruby/2.3.0/fileutils.rb:1451:in `unlink': No such file or directory @ unlink_internal

[Chris Lamb]

Source: ruby-moneta
Version: 0.7.20-2.2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ruby-moneta fails to build from source in unstable/amd64:

  [..]

from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1359:in 
`load_spec_files'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:106:in `setup'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:92:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:78:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:45:in `invoke'
from /usr/bin/rspec:4:in `'
  rspec terminated with 1
  
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/helper.rb:52:in
 `block in ': undefined method `color_enabled=' for 
# (NoMethodError)
  Did you mean?  color_enabled?
from /usr/lib/ruby/vendor_ruby/rspec/core.rb:97:in `configure'
from 
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/helper.rb:50:in
 `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from 
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/moneta/standard_daybreak_spec.rb:3:in
 `'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1361:in 
`load'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1361:in 
`block in load_spec_files'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1359:in 
`each'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1359:in 
`load_spec_files'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:106:in `setup'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:92:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:78:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:45:in `invoke'
from /usr/bin/rspec:4:in `'
  rspec terminated with 1
  
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/helper.rb:52:in
 `block in ': undefined method `color_enabled=' for 
# (NoMethodError)
  Did you mean?  color_enabled?
from /usr/lib/ruby/vendor_ruby/rspec/core.rb:97:in `configure'
from 
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/helper.rb:50:in
 `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from 
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/moneta/transformer_marshal_sha384_spec.rb:3:in
 `'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1361:in 
`load'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1361:in 
`block in load_spec_files'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1359:in 
`each'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1359:in 
`load_spec_files'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:106:in `setup'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:92:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:78:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:45:in `invoke'
from /usr/bin/rspec:4:in `'
  rspec terminated with 1
  
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/helper.rb:52:in
 `block in ': undefined method `color_enabled=' for 
# (NoMethodError)
  Did you mean?  color_enabled?
from /usr/lib/ruby/vendor_ruby/rspec/core.rb:97:in `configure'
from 
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/helper.rb:50:in
 `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from 
/home/lamby/temp/cdt.20160701120841.WbzqAszk55.ruby-moneta/ruby-moneta-0.7.20/spec/moneta/semaphore_spec.rb:3:in
 `'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1361:in 
`load'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1361:in 
`block in load_spec_files'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1359:in 
`each'
from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1359:in 
`load_spec_files'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:106:in `setup'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:92:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:78:in `run'
from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:45:in `invoke'
from /usr/bin/rspec:4:i

Bug#784572: file: weak magic for Embedded OpenType (EOT)

[Christoph Biedl]

tags 784572 confirmed upstream
thanks

Tim Bagot wrote...

> A colleague was surprised to find a C++ source file misdetected as
> "Embedded OpenType (EOT)". Surprisingly, the magic definition for
> that type relies on just 2 ASCII bytes:

Yuck, that's ugly. For a quick and dirty fix you can replace

> # EOT
> 34string  LP  Embedded OpenType (EOT)

with

0x40string  \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
>0x22   string  LP  Embedded OpenType (EOT)

by exploiting the fact these 16 "reserved" octets should be zero. You
could do me a favour by validating it against your available .eot
files.

Also, I'll come up with something nicer which needs some preparation,
though. Days, not months.

Christoph


signature.asc
Description: Digital signature

Bug#829197: bugzilla-cli: Description should not mention Python version

[Ben Finney]

Package: bugzilla-cli
Version: 1.2.2-1
Severity: minor

Dear Maintainer,

The recommendation to specify Python version in the package
description is limited only to packages where the person installing
the package needs to care about what Python version is supported.

The package ‘bugzilla-cli’ installs primarily an application, of
interest regardless of the programming language. Its description
should not mention that it is implemented in Python, because that is
not relevant to the functionality of the package.

I suggest this description field instead:

Description: command-line tool for interacting with Bugzilla
bugzilla-cli is a command-line tool for interacting with
Bugzilla instances from shell scripts.

-- 
 \“Science doesn't work by vote and it doesn't work by |
  `\authority.” —Richard Dawkins, _Big Mistake_ (The Guardian, |
_o__)  2006-12-27) |
Ben Finney 


signature.asc
Description: PGP signature

Bug#829196: krb5: Bad control field name build-depends-indep

[Александр Волков]

Package: krb5
Version: 1.14.2+dfsg-1

Please, replace build-depends-indep by Build-Depends-Indep.

Bug#829198: xserver-xorg-video-radeon: G4/MDD/X800XT freezes with black desktop if firmware-linux-nonfree installed.

[Mathieu Malaterre]

Package: xserver-xorg-video-radeon
Version: 1:7.5.0-1
Severity: important

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?
   * What outcome did you expect instead?

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


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jun 12 16:58 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2498728 Feb 11  2015 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
:00:10.0 VGA compatible controller [0300]: Advanced Micro Devices,
Inc. [AMD/ATI] R420 GL [FireGL X3-256] [1002:4a4d] (rev 80)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 3.16.0-4-powerpc-smp (debian-ker...@lists.debian.org)
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian
3.16.7-ckt25-2+deb8u2 (2016-06-25)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 47432 Jun 30 14:19 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[19.433]
X.Org X Server 1.11.3
Release Date: 2011-12-16
[19.433] X Protocol Version 11, Revision 0
[19.433] Build Operating System: Linux 3.13.0-63-powerpc-smp ppc Ubuntu
[19.433] Current Operating System: Linux debian-g4
3.16.0-4-powerpc-smp #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) ppc
[19.433] Kernel command line:
root=UUID=e9b51525-136e-4bf4-9b54-cba053d4fb4f ro radeon.agpmode=-1
[19.434] Build Date: 12 September 2015  03:43:47PM
[19.434] xorg-server 2:1.11.4-1blossom1 (For technical support
please see http://www.ubuntu.com/support)
[19.434] Current version of pixman: 0.32.6
[19.434] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[19.434] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[19.435] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jun 30
14:19:15 2016
[19.441] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[19.452] (==) No Layout section.  Using the first Screen section.
[19.452] (==) No screen section available. Using defaults.
[19.452] (**) |-->Screen "Default Screen Section" (0)
[19.452] (**) |   |-->Monitor ""
[19.453] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[19.453] (==) Automatically adding devices
[19.453] (==) Automatically enabling devices
[19.472] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[19.472] Entry deleted from font path.
[19.496] (WW) The directory
"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist.
[19.496] Entry deleted from font path.
[19.496] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[19.496] (==) ModulePath set to
"/usr/lib/powerpc-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[19.496] (II) The server relies on udev to provide the list of
input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[19.497] (II) Loader magic: 0x2043c584
[19.497] (II) Module ABI versions:
[19.497] X.Org ANSI C Emulation: 0.4
[19.497] X.Org Video Driver: 11.0
[19.497] X.Org XInput driver : 16.0
[19.497] X.Org Server Extension : 6.0
[19.499] (--) PCI:*(0:0:16:0) 1002:4a4d:1002:4a4d rev 128, Mem @
0xa000/268435456, 0x9000/65536, I/O @ 0x0400/256, BIOS @
0x/131072
[19.499] (II) LoadModule: "extmod"
[19.513] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[19.520] (II) Module extmod: vendor="X.Org Foundation"
[19.520] compiled for 1.11.3, module version = 1.0.0
[19.520] Module class: X.Org Server Extension
[19.520] ABI class: X.Org Server Extension, version 6.0
[19.520] (II) Loading extension MIT-SCREEN-SAVER
[19.520] (II) Loading extension XFree86-VidModeExtension
[19.520] (II) Loading extension XFree86-DGA
[19.521] (II) Loading extension DPMS
[19.521] (II) Loading extension XVideo
[19.521] (II) Loading extension XVideo-MotionCompensation
[19.521] (II) Loading extension X-Resource
[19.521] (II) LoadModule: "dbe"
[19.522] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[19.528] (II) Module 

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

Hi Gianfranco ,

Sorry for the delay, but it's difficult for me to debug those tests
because I can't run the tests in any local / remote machine...

A few days after this bug report, I applied to become a DM (via my
sponsor) in part as a way to be able to run these tests in Debian
infraestructure.
Do you know of another way to quickly do tests on those big-endian platforms?

As an alternative, I can submit a patch to just skip those tests in
big-endian platforms and leave this for future fix and in the
meanwhile unblock the transition in Ubuntu.

JL


On Fri, Jul 1, 2016 at 12:07 PM, Gianfranco Costamagna
 wrote:
> Hi Jose, do you have any ETA for this issue?
>
> this is preventing the opencv decruft, and the transition in Ubuntu.
>
> thanks
>
> Gianfranco
>

Bug#825359: sbuild: unrealistic figure about total space used

[Santiago Vila]

On Fri, 1 Jul 2016, Johannes Schauer wrote:

> Could you maybe:
> 
>  1. use debootstrap to create a new chroot
>  2. bind-mount /dev, /proc and /sys into that
>  3. chroot into the directory
>  4. install sbuild
>  5. run sbuild-update --keygen
>  6. run sbuild-createchroot
>  7. build a package
> 
> For me, following these steps lets sbuild produce the expected output. Can you
> confirm this? I can also send you a sequence of command line invocations to
> achieve the above if that makes things easier for you.
> 
> If you can confirm this, can you show me what the difference is between that
> setup and yours?

I'll try, but before that I would like to do a little bit of
"data mining" on my collection of build logs.

Maybe there is a pattern that would point to the cause for this.

As of now, I don't even know which is the smallest package on which this
effect happens.

Thanks.

Bug#823148: unison: Unison 2.48.3 crashes when syncing to a Ubuntu xenian host with same version if file>700 bytes

[Niels Elgaard Larsen]

On Sun, 01 May 2016 14:16:59 + Daniel Alder
 wrote:
> Package: unison
> Version: 2.48.3-1
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?

unison marshalls data in datastructures dependent on the ocaml version
it was build with.

So even for the same version of unison you have to choose to be
compatible with e.g. Ubuntu, Debian stable, etc.

Right now if you just build unison from source on Sid it works with
Ubuntu Xenian.

But put it on hold when it works.


> I tried to sync using unison between an up-to-date Debian stretch and a 
> Ubuntu xenial host, both have the same unison version:
> 
> Debian:
> ii  unison 2.48.3-1 amd64file-synchronization tool for 
> Unix and Windows
> Ubuntu:
> ii  unison 2.48.3-1ubuntu1 amd64   
> file-synchronization tool for Unix and Windows
> 
> 
> I discovered that the Debian side crashes whenever a file with size 701 bytes 
> or
> bigger has to be transferred from debian to ubuntu.
> The error does NOT appear if the file on the other side doesn't exist yet.
> The error also doesn't appear if both systems are Ubuntu or if both are 
> Debian.
> 
> 
> == Here is a test matrix: ==
> 
>  debian file
>  =700 bytes  =701 bytes
> ubuntu file =700 bytes   d->u ok, u->d okd->u ok, u->d ok
> =701 bytes   d->u ok, u->d okd->u err, u->d ok
> 
> explanation: d->u means transfer from debian to ubuntu, no matter which side
> runs unison, only the final direction of the file transfer is relevant, see 
> logs
> below.
> 
> 
> == Error log when running on Debian side: ==
> 
> synctest@debian:~$ unison myfolder/ ssh://$remoteip/myfolder/
> Contacting server...
> Connected [//debian//home/synctest/myfolder -> 
> //ubuntu//home/synctest/myfolder]
> Looking for changes
>   Waiting for changes from server
> Reconciling changes
> 
> local  ubuntu 
> changed  > changedtestfile  [] >
> 
> Proceed with propagating updates? [] y
> Propagating updates
> 
> 
> UNISON 2.48.3 started propagating changes at 13:31:35.72 on 01 May 2016
> [BGN] Updating file testfile from /home/synctest/myfolder to 
> //ubuntu//home/synctest/myfolder
> Uncaught exception Failure("input_value: bad bigarray kind")
> Raised by primitive operation at file "/tmp/buildd/unison-2.48.3/remote.ml", 
> line 453, characters 18-45
> Called from file "/tmp/buildd/unison-2.48.3/remote.ml", line 459, characters 
> 23-61
> Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 75, characters 
> 20-23
> Re-raised at file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 135, 
> characters 12-13
> Called from file "list.ml", line 73, characters 12-15
> Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 31, characters 
> 2-37
> Called from file "/tmp/buildd/unison-2.48.3/lwt/lwt.ml", line 83, characters 
> 17-46

-- 
Niels Elgaard Larsen

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[Gianfranco Costamagna]

Hi,

>Sorry for the delay, but it's difficult for me to debug those tests
>because I can't run the tests in any local / remote machine...
>
>A few days after this bug report, I applied to become a DM (via my
>sponsor) in part as a way to be able to run these tests in Debian
>infraestructure.
>Do you know of another way to quickly do tests on those big-endian platforms?


I have an ongoing build of the current git master on zelenka.debian.org.
If you have tests/patches, ask me and I'll perform them
(build at 40%)

this is an s390x machine

>As an alternative, I can submit a patch to just skip those tests in
>big-endian platforms and leave this for future fix and in the
>meanwhile unblock the transition in Ubuntu.


if you can unblock the transition this would be great, just ping and I'll 
sponsor
it.
(I can also unblock just Ubuntu, and see Debian fixed properly, there is no 
real rush,
as soon as the transition lands in -release)

thanks!

G.


On Fri, Jul 1, 2016 at 12:07 PM, Gianfranco Costamagna
 wrote:
> Hi Jose, do you have any ETA for this issue?
>
> this is preventing the opencv decruft, and the transition in Ubuntu.
>
> thanks
>
> Gianfranco
>

Bug#811682: Updated patch

[Gert Wollny]

Hi,

I've updated the patch according to my last comment and also tested it
with g++-5 (i.e. without -std=c++11) and it  builds successfully. 

Note however that their are lintian errors: 

E: libgtkmathview-dev: pkg-config-multi-arch-wrong-dir
usr/lib/pkgconfig/gtkmathview-gmetadom.pc full text contains
architecture specific dir x86_64-linux-gnu

E: libgtkmathview-dev: pkg-config-multi-arch-wrong-dir 
usr/lib/pkgconfig/mathview-frontend-gmetadom.pc full text contains
architecture specific dir x86_64-linux-gnu

Best, 
Gert 
 
From: Gert Wollny 
Date: Sun, 26 Jun 2016 13:25:00 +0200
Description: gcc 6.0 build fixes
Bug: https://bugs.debian.org/811682

--- a/src/engine/common/View.cc
+++ b/src/engine/common/View.cc
@@ -291,7 +291,7 @@
 	  }
 }
 
-  return false;
+  return SmartPtr();
 }
 
 bool
--- a/src/backend/common/tfm/TFM.hh
+++ b/src/backend/common/tfm/TFM.hh
@@ -37,7 +37,7 @@
 unsigned char face;
 const char* codingScheme;
 int designSize;
-int checksum;
+unsigned int checksum;
 unsigned int nDimensions;
 unsigned int nCharacters;
   };
@@ -52,7 +52,7 @@
   struct Kerning
   {
 UChar8 index;
-int value;
+unsigned int value;
   };
 
   struct Ligature
@@ -67,7 +67,7 @@
 UChar8 index;
 int width;
 int height;
-int depth;
+unsigned int depth;
 int italicCorrection;
 unsigned char nKernings;
 const Kerning* kerning;
--- a/src/backend/common/ComputerModernShaper.cc
+++ b/src/backend/common/ComputerModernShaper.cc
@@ -578,7 +578,7 @@
   };
 #endif
 
-static ComputerModernShaper::PlainChar cmsMap[] =
+static ComputerModernShaper::PlainChar32 cmsMap[] =
   {
 { 0x007B, 0x66 },  // LEFT CURLY BRACKET
 { 0x007D, 0x67 },  // RIGHT CURLY BRACKET
--- a/src/backend/common/StandardSymbolsShaper.hh
+++ b/src/backend/common/StandardSymbolsShaper.hh
@@ -32,20 +32,20 @@
   struct HStretchyChar
   {
 Char16 ch;
-Char8 normal;
-Char8 left;
-Char8 glue;
-Char8 right;
+UChar8 normal;
+UChar8 left;
+UChar8 glue;
+UChar8 right;
   };
   
   struct VStretchyChar
   {
 Char16 ch;
-Char8 normal;
-Char8 top;
-Char8 glue;
-Char8 middle;
-Char8 bottom;
+UChar8 normal;
+UChar8 top;
+UChar8 glue;
+UChar8 middle;
+UChar8 bottom;
   };
 
 protected:
--- a/src/backend/common/StandardSymbolsShaper.cc
+++ b/src/backend/common/StandardSymbolsShaper.cc
@@ -29,7 +29,7 @@
 #include "ShapingContext.hh"
 
 struct GlyphMap {
-  Char8 index;
+  UChar8 index;
   Char16 ch;
 };
 

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

control: noowner -1
control: tag -1 +confirmed -moreinfo

Hello Dmitry,

My apologies for wasting your time -- I can't reproduce it now.

I added a "Forwarded: not-needed" header and I think we're done here :)
Thank you for your time.  The only thing I couldn't test is a clean
build in pbuilder/sbuild which isn't possible due to the dtach issue.

You might consider re-running dch -r to refresh the timestamp in the
changelog so it lies after all our changes.

-- 
Sean Whitton

Bug#811667: cal3d: Patch

[Alberto Luaces]

Source: cal3d
Followup-For: Bug #811667

I spoke too soon: recent code does not show those errors, but the rest
does have them.

Anyway, here is a patch that solves the issue.
diff -ruN cal3d-0.11.0/src/cal3d/loader.cpp cal3d-0.11.0-changes/src/cal3d/loader.cpp
--- cal3d-0.11.0/src/cal3d/loader.cpp	2006-06-08 17:12:13.0 +0200
+++ cal3d-0.11.0-changes/src/cal3d/loader.cpp	2016-07-01 13:04:45.732750815 +0200
@@ -886,7 +886,7 @@
   if(!dataSrc.ok())
   {
 dataSrc.setError();
-return false;
+return 0;
   }
 
   // allocate a new core keyframe instance
@@ -1338,13 +1338,13 @@
 		if(stricmp(skeleton->Attribute("MAGIC"),Cal::SKELETON_XMLFILE_MAGIC)!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		if(atoi(skeleton->Attribute("VERSION")) < Cal::EARLIEST_COMPATIBLE_FILE_VERSION )
 		{
 			CalError::setLastError(CalError::INCOMPATIBLE_FILE_VERSION, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		skeleton = skeleton->NextSiblingElement();
@@ -1353,19 +1353,19 @@
 	if(!skeleton || stricmp(skeleton->Value(),"SKELETON")!=0)
 	{
 		CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-		return false;
+		return 0;
 	}
 
 	if(skeleton->Attribute("MAGIC")!=NULL && stricmp(skeleton->Attribute("MAGIC"),Cal::SKELETON_XMLFILE_MAGIC)!=0)
 	{
 		CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-		return false;
+		return 0;
 	}
 
 	if(skeleton->Attribute("VERSION")!=NULL && atoi(skeleton->Attribute("VERSION")) < Cal::EARLIEST_COMPATIBLE_FILE_VERSION )
 	{
 		CalError::setLastError(CalError::INCOMPATIBLE_FILE_VERSION, __FILE__, __LINE__, strFilename);
-		return false;
+		return 0;
 	}
 
 
@@ -1383,7 +1383,7 @@
 		if(stricmp(bone->Value(),"BONE")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		std::string strName=bone->Attribute("NAME");
@@ -1395,7 +1395,7 @@
 		if(!translation || stricmp( translation->Value(),"TRANSLATION")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		float tx, ty, tz;
@@ -1404,13 +1404,13 @@
 		if(!node)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		TiXmlText* translationdata = node->ToText();
 		if(!translationdata)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		str.clear();
 		str << translationdata->Value();
@@ -1422,7 +1422,7 @@
 		if(!rotation || stricmp(rotation->Value(),"ROTATION")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		float rx, ry, rz, rw;
@@ -1431,13 +1431,13 @@
 		if(!node)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		TiXmlText* rotationdata = node->ToText();
 		if(!rotationdata)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		str.clear();
 		str << rotationdata->Value();
@@ -1450,7 +1450,7 @@
 		if(!rotation || stricmp(translationBoneSpace->Value(),"LOCALTRANSLATION")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		float txBoneSpace, tyBoneSpace, tzBoneSpace;
@@ -1459,13 +1459,13 @@
 		if(!node)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		TiXmlText* translationBoneSpacedata = node->ToText();
 		if(!translationBoneSpacedata)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		str.clear();
 		str << translationBoneSpacedata->Value();
@@ -1477,7 +1477,7 @@
 		if(!rotationBoneSpace || stricmp(rotationBoneSpace->Value(),"LOCALROTATION")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		float rxBoneSpace, ryBoneSpace, rzBoneSpace, rwBoneSpace;
@@ -1486,13 +1486,13 @@
 		if(!node)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		TiXmlText* rotationBoneSpacedata = node->ToText();
 		if(!rotationBoneSpacedata)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		str.clear();
 		str << rotationBoneSpacedata->Value();
@@ -1504,7 +1504,7 @@
 		if(!parent ||stricmp(parent->Value(),"PARENTID")!=0)
 		{
 			CalError::set

Bug#827907: RFS: evil/1.2.12-1 ITP

[Gianfranco Costamagna]

control: owner -1 !

Hi,

>You might consider re-running dch -r to refresh the timestamp in the
>changelog so it lies after all our changes.


and ping when ready :)

G.

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Sean Whitton]

control: tag -1 -moreinfo +confirmed
control: noowner -1

Hello,

On Fri, Jul 01, 2016 at 12:11:35PM +0300, Dmitry Bogatov wrote:
> Added Forwarded: header at bootom of description. It works. If I add it at 
> top,
> it will be lost during patch->commit->patch conversion.

Okay.  I think that fails DEP-3 but that might be okay for the sake of
sane gbp usage.  Up to the judgment of the DD who sponsors!

Thanks for your patience.

-- 
Sean Whitton

Bug#815239: move css into debian.css

[Stéphane Blondon]

This version provides the same rendering of the 2 forms but the CSS
style is included into debian.css instead of having it inline in the
HTML code.

The diff files were generated with `cvs diff ${filename}`.
Index: ../debian.css
===
RCS file: /cvs/webwml/webwml/english/debian.css,v
retrieving revision 1.103
diff -r1.103 debian.css
894a895,904
> 
> /* 
>  * For form
>  */
> 
> .action-block-form {
> margin-left: 4em;
> }
> 
> 
Index: search_contents-form.inc
===
RCS file: /cvs/webwml/webwml/english/distrib/search_contents-form.inc,v
retrieving revision 1.18
diff -r1.18 search_contents-form.inc
7c7
< 
---
> 
10,13c10,12
<   
< Search" />
<  Reset" />
< 
---
> 
> 
> 
24c23,24
< 
---
> 
> 
46c46,50
< 
---
> 
> 
>   Search" />
>   Reset" />
> 
Index: search_packages-form.inc
===
RCS file: /cvs/webwml/webwml/english/distrib/search_packages-form.inc,v
retrieving revision 1.14
diff -r1.14 search_packages-form.inc
7c7
< 
---
> 
10,11c10,11
< Search" /> Reset" />
< 
---
> 
> 
19c19,20
< 
---
> 
> 
22c23,24
< 
---
> 
> 
39c41,45
< 
---
> 
> 
>   Search" />
>   Reset" />
> 


signature.asc
Description: OpenPGP digital signature

Bug#811676: FTBFS with GCC 6: could not convert a from x to y

[Robert Bihlmeyer]

Package: fbreader
Followup-For: Bug #811676

Looks legit. Simple fix attached.
diff -ru fbreader-0.12.10dfsg2/fbreader/src/database/booksdb/BooksDB.cpp fbreader-0.12.10dfsg2+/fbreader/src/database/booksdb/BooksDB.cpp
--- fbreader-0.12.10dfsg2/fbreader/src/database/booksdb/BooksDB.cpp	2010-04-01 15:14:24.0 +0200
+++ fbreader-0.12.10dfsg2+/fbreader/src/database/booksdb/BooksDB.cpp	2016-07-01 13:24:36.919070856 +0200
@@ -145,7 +145,7 @@
 
 	myFindFileId->setFileName(fileName);
 	if (!myFindFileId->run()) {
-		return false;
+		return 0;
 	}
 	((DBIntValue&)*myLoadBook->parameter("@file_id").value()) = myFindFileId->fileId();
 	shared_ptr reader = myLoadBook->executeReader();

Bug#829200: dh-elpa: Could dh-elpa be told to use debian version as elpa version

[Remi Vanicat]

Package: dh-elpa
Version: 0.0.21
Severity: wishlist

Some elpa package do not have the ";; Version:" (for example magit, and
other package made by the magit developers), but in most situation, the
elpa package version is the upstream part of the debian source
version.

Adding an way to let dh-elpa know this, would be cool. Or maybe just an
option to tell it what elpa version there is (setting
"DH_ELPA_VERSION=$(DEB_VERSION_UPSTREAM)" would do in most case, but
letting more complex stuff possible).

The hack used in magit to let dh-elpa know the version is there, if this
is useful.

http://anonscm.debian.org/cgit/pkg-emacsen/pkg/magit.git/tree/debian/rules?id=3e3f6490b788b95e2b990f71ee097771c2b311a9

Maybe no the simple way to do it.

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

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

Versions of packages dh-elpa depends on:
ii  dh-make-perl0.90-1
ii  emacs24 24.5+1-6+b2
ii  libarray-utils-perl 0.5-1
ii  libfile-find-rule-perl  0.34-1
ii  perl5.22.2-1

dh-elpa recommends no packages.

dh-elpa suggests no packages.

-- no debconf information

-- 
Rémi Vanicat

>  LocalWords:  debian dh elpa magit

Bug#829199: file: misdetection: SVG file without tag is recognised as HTML

[Paul Wise]

Package: file
Version: 1:5.28-2
Severity: normal

This SVG file is recognised as HTML instead of SVG and it appears to be
because it is missing the usual XML header. Despite the missing XML
header, it is still viewable in Firefox and rsvg.

$ wget -q https://endlessm.com/wp-content/themes/endless/img/logo.svg
$ file logo.svg
logo.svg: HTML document, ASCII text, with very long lines, with no line 
terminators
$ file --mime logo.svg
logo.svg: text/html; charset=us-ascii
$ ( echo '' ; cat logo.svg ) | sponge 
logo.svg
$ file logo.svg
logo.svg: SVG Scalable Vector Graphics image
$ file --mime logo.svg
logo.svg: image/svg+xml; charset=us-ascii
$ fmt -s logo.svg | head -n4

http://www.w3.org/2000/svg"; viewBox="0 0 615.98
72.38">.cls-1{fill:#ea5b0c;}.cls-2{fill:#4a4a49;}logohttps://wiki.debian.org/PaulWise


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

Bug#829203: libpaper1: Wrong size of C4 paper

[Martin Mares]

Package: libpaper1
Version: 1.1.24+nmu4
Severity: normal

Hello!

I noticed that the dimensions of the C4 paper are reported by
'paperconf -whm c4' as '229 mm 354 mm', but the correct values
are '229 mm 324 mm'.

The other ISO Cn formats are correct.


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

Kernel: Linux 4.4.0-kam (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libpaper1 depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  libc6  2.19-18+deb8u4
ii  multiarch-support  2.19-18+deb8u4
ii  ucf3.0030

Versions of packages libpaper1 recommends:
ii  libpaper-utils  1.1.24+nmu4

libpaper1 suggests no packages.

-- debconf information:
  libpaper/defaultpaper: a4

Bug#827907: RFS: evil/1.2.12-1 ITP

[Ansgar Burchardt]

On Fri, 2016-07-01 at 08:13 +, Sean Whitton wrote:
> On Thu, Jun 30, 2016 at 10:24:51PM +0200, Jakub Wilk wrote:
> > * Dmitry Bogatov , 2016-06-30, 22:28:
> > > * default configuration of pbuilder do not provide possibility to
> > > allocate
> > > pty
> > 
> > Sounds like a bug in pbuilder.
> > 
> > > So, question is whether it is possible to allocate pty on Debian
> > > build
> > > farm.
> > 
> > Yes.
> 
> It seems that vanilla sbuild has the same problem (tested locally and
> on
> deb-o-matic), so it seems like the buildds are using some special
> sbuild
> configuration to permit allocating ptys.
> 
> I would be grateful, Jakub, if you could try the build on your sbuild
> config before I file a bug against sbuild suggesting this be the
> default.  The repo, for your convenience:
> https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el

It depends on the version of debootstrap in use. See [1].

Ansgar

  [1] 

Bug#827907: RFS: evil/1.2.12-1 ITP

[Jakub Wilk]

* Sean Whitton , 2016-07-01, 08:13:
I would be grateful, Jakub, if you could try the build on your sbuild 
config before I file a bug against sbuild suggesting this be the 
default.  The repo, for your convenience:

https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el


Why .orig.tar from pristine-tar is different than the on uscan 
downloads?


I tried to build the package in sbuild in a (clean but not quite 
up-to-date) VM, and it indeed FTBFS:


dtach -n debian/elpa-test.sock sh -c '/usr/bin/make test && touch 
debian/elpa-test.ok'
dtach: Could not find a pty.
debian/rules:21: recipe for target 'override_dh_elpa_test' failed


I don't understand why, though.
/dev/pts is mounted in the chroot, as it should...

--
Jakub Wilk

Bug#829199: file: misdetection: SVG file without tag is recognised as HTML

[Christoph Biedl]

tags 829199 confirmed upstream
thanks

Paul Wise wrote...

> This SVG file is recognised as HTML instead of SVG and it appears to be
> because it is missing the usual XML header. Despite the missing XML
> header, it is still viewable in Firefox and rsvg.

That's correct, and hopefully I can find a solution that can handle
such a situation without creating false positives.

Christoph


signature.asc
Description: Digital signature

Bug#829204: nowhere generates incorrect SML code

[Hubert Garavel]

Package: nowhere
Version: 110.79

When we invoke nowhere on a small file test.now, it generates
a file test.sml that contains undefined variable. test.sml
is then rejected by the compiler.

This is an example of problematic file test.now

<<<
local

datatype xbool = Xtrue | Xfalse
and strg = Xa | Xb | C of strg * strg;
in
datatype xbool = Xtrue | Xfalse
and strg = Xa | Xb | C of strg * strg;

fun gte (x1:strg, x2:strg ): xbool =
case (x1, x2) of
(Xa, Xa) => Xtrue
| (C (e, s), e2) => gte (e, e2)
| (e, C (e2, s2)) where e = e2 => Xfalse

fun main () =(
  print "\n"
)

val _ = main ()

end
>>>

When we run the official nowhere tool installed on Debian jessie
(x86, 32 bits):

$ /usr/bin/nowhere @SMLversion
nowhere 110.76

$ /usr/bin/sml @SMLversion
sml 110.76

$ /usr/bin/nowhere test.now
test.now:9.1-13.41: warning: non-exhaustive matches
(Xa, Xa) => ...
(C(e, s), e2) => ...
(e, C(e2, s2)) where ... => ...
[Generating test.sml]

The generated SML file contains references to undefined variables
v_1 and v_5, and is then rejected by the SML compiler:

$ /usr/bin/sml test.sml
Standard ML of New Jersey v110.76 [built: Mon Jul 7 16:22:48 2014]
[opening test.sml]
test.now:14.34-14.37 Error: unbound variable or constructor: v_1
test.now:16.28-16.31 Error: unbound variable or constructor: v_5
/usr/lib/smlnj/bin/sml: Fatal error -- Uncaught exception Error with 0
raised at ../compiler/TopLevel/interact/evalloop.sml:66.19-66.27


We observed also the same issue on the latest version 110.79 of
Nowhere and SML:

$ nowhere test.now
test.now:9.1-13.41: warning: non-exhaustive matches
(Xa, Xa) => ...
(C(e, s), e2) => ...
(e, C(e2, s2)) where ... => ...
[Generating test.sml]

$ sml test.sml
Standard ML of New Jersey v110.79 [built: Thu Jun 23 15:18:54 2016]
[opening test.sml]
test.now:14.34-14.37 Error: unbound variable or constructor: v_1
test.now:16.28-16.31 Error: unbound variable or constructor: v_5
/home/mtabikh/SML/bin/sml: Fatal error -- Uncaught exception Error with 0
raised at ../compiler/TopLevel/interact/evalloop.sml:66.19-66.27


Enclosed is the generated file test.sml:


(* WARNING: this is generated by running 'nowhere test.now'.
 * Do not edit this file directly.
 * Version 1.2.2
 *)

(*#line 6.1 "test.now"*)
datatype xbool =
  Xtrue
| Xfalse
and strg =
  Xa
| Xb
| C of strg * strg

(*#line 9.1 "test.now"*)
fun gte ((x1:strg), (x2:strg)) = (
let val v_6 = (x1, x2)
fun state_0 () = raise Match
fun state_8 () =
let val (v_8, v_7) = v_1
in
   let val e = v_5
   and e2 = v_8
   and s2 = v_7
   in (if (e = e2)
 then Xfalse
 else (state_0 ()))
   end
end
in
   let val (v_5, v_0) = v_6
   in
  (case v_5 of
C v_4 =>
let val (v_3, v_2) = v_4
in
   let val e = v_3
   and e2 = v_0
   and s = v_2
   in gte (e, e2)
   end
end
  | Xa =>
(case v_0 of
  C v_1 => state_8 ()
| Xa => Xtrue
| Xb => state_0 ()
)
  | Xb =>
(case v_0 of
  C v_1 => state_8 ()
| _ => state_0 ()
)
  )
   end
end : xbool)

(*#line 15.1 "test.now"*)
fun main () = print "\n"

(*#line 19.1 "test.now"*)
val _ = main ()


Best regards
Hubert Garavel and Mohammad-Ali Tabikh

-- 
',',',',',',',',',',' Hubert GARAVEL   | Inria - LIG / CONVECS
',',',',',',',',',',' hubert.gara...@inria.fr  | 655, avenue de l'Europe
',',',',',',',',',',' tel: +(33) 4 76 61 52 24 | 38330 Montbonnot St Martin
',',',',',',',',',',' twitter: @convecs| France
',',',',',',',',',',' http://convecs.inria.fr/people/Hubert.Garavel

Bug#783508: there are more issues than just spec.files

[Pirate Praveen]

its better to drop this gemspec altogether and package
rails-assets-jquery.ui separately.



signature.asc
Description: OpenPGP digital signature

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for this update of "btrfs-progs".  I have
chosen to update to v4.5.3, because this version does not trigger a
bug when combined with linux-4.6.x as discussed in the following
email:
https://www.spinics.net/lists/linux-btrfs/msg56664.html

If the two patches discussed in this email are merged into linux-4.7,
I plan to package btrfs-progs-4.6.1 or v4.7 when linux-4.7 is uploaded
to unstable:
https://www.spinics.net/lists/linux-btrfs/msg56659.html

Alternatively, this bug might be fixed in btrfs-progs-4.7.  For now,
lets use 4.5.3!  Here is the upstream changelog post-4.5.2:

  * ioctl: fix unaligned access in buffer from TREE_SEARCH; might cause SIGBUS
on architectures that do not support unaligned access and do not perform
any fixups
  * improved validation checks of superblock and chunk-related structures
  * subvolume sync: fix handling of -s option
  * balance: adjust timing of safety delay countdown with --full-balance
  * rescue super-recover: fix reversed condition check
  * check: fix bytes_used accounting
  * documentation updates: mount options, scrub, send, receive, select-super,
check, mkfs
  * testing: new fuzzed images, for superblock and chunks

Package name: btrfs-progs
Version: 4.5.3-0.1
Section: admin

It builds these binary packages:

btrfs-progs - Checksumming Copy on Write Filesystem utilities
btrfs-progs-dbg - Checksumming Copy on Write Filesystem utilities (debug)
btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) (udeb)
btrfs-tools - transitional dummy package
btrfs-tools-dbg - transitional dummy package

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

  https://mentors.debian.net/package/btrfs-progs

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.5.3-0.1.dsc

Changes since the last upload:

  * Non-maintainer upload.
  * New upstream release.
  * Update standards version to 3.9.8 (no changes needed).
  * Install upstream changelog. (Closes: #824894)
  * Fix serious errors in debian/copyright.  This is not a GPL2+ package.
Cme was used to generate a machine-readable copyright file, then
manual fixes were made. (Closes: #824896)
  * Add mangling rules to debian/watch to prefer non-rcN versions;
  * Add cryptographic signature verification of tarball.

Thank you,
Nicholas

Bug#828422: Fwd: Bug#828422: links2: FTBFS with openssl 1.1.0

[Mikulas Patocka]

On Fri, 1 Jul 2016, Axel Beckert wrote:

> Hi Mikulas,
> 
> Mikulas Patocka wrote:
> > I released Links 2.13, so you can make a new Debian package.
> 
> Thanks, will do!
> 
> BTW, Is it on purpose that OpenSSL 1.1 support is not mentioned in
> http://links.twibright.com/download/ChangeLog?

I forgot to add a note to the ChangeLog file.

Mikulas

Bug#829162: segfault upon warning message

[Dmitry Baryshnikov]

Segmentation fault was fixed in r34493 
(https://trac.osgeo.org/gdal/changeset/34493).

--
Best regards,
Dmitry

Bug#829206: ITP: ruby-github-api -- ruby client for the official GitHub API

[李健秋]

Package: wnpp
Severity: wishlist
Owner: "Andrew Lee (李健秋)" 

* Package name: ruby-github-api
  Version : 0.14.2
  Upstream Author : Piotr Murach
* URL : https://rubygems.org/gems/github_api/
* License : MIT
  Programming Lang: Ruby
  Description : ruby client for the official GitHub API

   Ruby-github-api is a ruby client that supports all of the GitHub API
   methods. It's build in a modular way, that is, you can either
   instantiate the whole api wrapper Github.new or use parts of it.
   .
   e.i. Github::Client::Repos.new if working solely with repositories
   is your main concern.
   .
   Intuitive query methods allow you easily call API endpoints.

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[Gianfranco Costamagna]

Hi,


>Is experimental available for this purpose?



it is, I'm uploading shortly, I did a dget

changed unstable to experimental in changelog, and if everything is good I'll 
upload

BTW skimage didn't migrate
https://packages.qa.debian.org/s/skimage.html
I would prefer to avoid overriding of the testsuite, so we might end up in
1) fixing the build failures
2) restrict caffe on the success architectures

cheers,

G.

Bug#828990: xerces-c: diff for NMU version 3.1.3+debian-2.1

[Salvatore Bonaccorso]

Control: tags 828990 + pending

Hi,

I've prepared an NMU for xerces-c (versioned as 3.1.3+debian-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru xerces-c-3.1.3+debian/debian/NEWS xerces-c-3.1.3+debian/debian/NEWS
--- xerces-c-3.1.3+debian/debian/NEWS	1970-01-01 01:00:00.0 +0100
+++ xerces-c-3.1.3+debian/debian/NEWS	2016-07-01 14:29:28.0 +0200
@@ -0,0 +1,9 @@
+xerces-c (3.1.3+debian-2.1) unstable; urgency=medium
+
+  In addition to the fix for CVE-2016-4463 this update enables applications to
+  fully disable DTD processing through the use of an environment variable.
+  .
+  XERCES_DISABLE_DTD set to "1" will cause the scanner to report a fatal error
+  if a DTD is seen. Existing applications won't see any change.
+
+ -- Salvatore Bonaccorso   Tue, 28 Jun 2016 16:50:55 +0200
diff -Nru xerces-c-3.1.3+debian/debian/changelog xerces-c-3.1.3+debian/debian/changelog
--- xerces-c-3.1.3+debian/debian/changelog	2016-05-10 07:14:49.0 +0200
+++ xerces-c-3.1.3+debian/debian/changelog	2016-07-01 14:29:28.0 +0200
@@ -1,3 +1,14 @@
+xerces-c (3.1.3+debian-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2016-4463: Apache Xerces-C XML Parser Crashes on Malformed DTD
+(Closes: #828990)
+  * Enable the ability to disable DTD processing through the use of an env
+variable
+  * Add NEWS.Debian entry to document the XERCES_DISABLE_DTD variable
+
+ -- Salvatore Bonaccorso   Fri, 01 Jul 2016 14:28:51 +0200
+
 xerces-c (3.1.3+debian-2) unstable; urgency=medium
 
   * Fix CVE-2016-2099: Exception handling mistake in DTDScanner.
diff -Nru xerces-c-3.1.3+debian/debian/patches/CVE-2016-4463.patch xerces-c-3.1.3+debian/debian/patches/CVE-2016-4463.patch
--- xerces-c-3.1.3+debian/debian/patches/CVE-2016-4463.patch	1970-01-01 01:00:00.0 +0100
+++ xerces-c-3.1.3+debian/debian/patches/CVE-2016-4463.patch	2016-07-01 14:29:28.0 +0200
@@ -0,0 +1,62 @@
+Description: CVE-2016-4463: Apache Xerces-C XML Parser Crashes on Malformed DTD
+Origin: upstream, https://svn.apache.org/r1747619
+Bug: https://issues.apache.org/jira/browse/XERCESC-2069
+Forwarded: not-needed
+Author: Scott Cantor 
+Last-Update: 2016-06-28
+
+--- a/src/xercesc/validators/DTD/DTDScanner.cpp
 b/src/xercesc/validators/DTD/DTDScanner.cpp
+@@ -44,6 +44,8 @@
+ 
+ XERCES_CPP_NAMESPACE_BEGIN
+ 
++#define CONTENTSPEC_DEPTH_LIMIT 1000
++
+ // ---
+ //  Local methods
+ // ---
+@@ -1038,8 +1040,13 @@ bool DTDScanner::scanCharRef(XMLCh& firs
+ 
+ 
+ ContentSpecNode*
+-DTDScanner::scanChildren(const DTDElementDecl& elemDecl, XMLBuffer& bufToUse)
++DTDScanner::scanChildren(const DTDElementDecl& elemDecl, XMLBuffer& bufToUse, unsigned int& depth)
+ {
++if (depth++ > CONTENTSPEC_DEPTH_LIMIT) {
++fScanner->emitError(XMLErrs::UnterminatedDOCTYPE);
++return 0;
++}
++
+ // Check for a PE ref here, but don't require spaces
+ checkForPERef(false, true);
+ 
+@@ -1240,7 +1247,7 @@ DTDScanner::scanChildren(const DTDElemen
+ // Recurse to handle this new guy
+ ContentSpecNode* subNode;
+ try {
+-subNode = scanChildren(elemDecl, bufToUse);
++subNode = scanChildren(elemDecl, bufToUse, depth);
+ }
+ catch (const XMLErrs::Codes)
+ {
+@@ -1577,7 +1584,8 @@ bool DTDScanner::scanContentSpec(DTDElem
+ //
+ toFill.setModelType(DTDElementDecl::Children);
+ XMLBufBid bbTmp(fBufMgr);
+-ContentSpecNode* resNode = scanChildren(toFill, bbTmp.getBuffer());
++unsigned int depth = 0;
++ContentSpecNode* resNode = scanChildren(toFill, bbTmp.getBuffer(), depth);
+ status = (resNode != 0);
+ if (status)
+ toFill.setContentSpec(resNode);
+--- a/src/xercesc/validators/DTD/DTDScanner.hpp
 b/src/xercesc/validators/DTD/DTDScanner.hpp
+@@ -143,6 +143,7 @@ private:
+ (
+ const   DTDElementDecl& elemDecl
+ ,   XMLBuffer&  bufToUse
++,   unsigned int&   depth
+ );
+ bool scanCharRef(XMLCh& toFill, XMLCh& second);
+ void scanComment();
diff -Nru xerces-c-3.1.3+debian/debian/patches/disable-DTD-processing-through-envvariable.patch xerces-c-3.1.3+debian/debian/patches/disable-DTD-processing-through-envvariable.patch
--- xerces-c-3.1.3+debian/debian/patches/disable-DTD-processing-through-envvariable.patch	1970-01-01 01:00:00.0 +0100
+++ xerces-c-3.1.3+debian/debian/patches/disable-DTD-processing-through-envvariable.patch	2016-07-01 14:29:28.0 +0200
@@ -0,0 +1,29 @@
+Description: Disable DTD processing through the use of an env variable
+ XERCES_DISABLE_DTD s

Bug#825849: powerdns 100% CPU usage

[Christian Hofstaedtler]

There's some more info in the forwarded upstream bug, but nobody has
so far been able to reproduce it. (See [1].)

Somebody thought this might be a locking issue introduced in the
botan update, but no hard facts.

[1] https://github.com/PowerDNS/pdns/issues/3954

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#829207: ITP: evil-paredit -- emacs extension, integrating evil and paredit

[Dmitry Bogatov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Bogatov 

* Package Name : evil-paredit
  Version  : 0.0.2
  Upstream Author  : Roman Gonzalez 
  Url  : https://github.com/roman/evil-paredit
  License  : MIT
  Programming Lang : Emacs Lisp
  Description  : emacs extension, integrating evil and paredit

 elpa-evil-paredit provides 'evil-paredit-mode', which redefines
 several evil keybindings to make it harder to get unbalanced brackets
 in buffer.

I plan to maintain this package as part of Emacsen team

Bug#811644: FTBFS with GCC 6: cannot convert x to y

[Gert Wollny]

Control: tags -1 pending 

Hi, 

I've uploaded a patch fixing this compiler problem, and I also added
another patch that makes sure the test suite is actually run during
package build. 

I don't ask for sponsoring though, because the package is somewhat
fishy:

In the source one gets by using 

  apt source idba 

no patches are applied or even listed. In the svn are two patches
however that are from 2014. They seem to be partially applied now, so
I've disabled one, and rebased the other. 

Also, when I run 

  svn-buildpackage 

the source tarball is not properly unpacked leaving me with an empty
tree and finally with an empty package. However, when I do 

   svn-buildpackage -S 

then the resulting source package is fine - i.e. I can unpack with
dpkg-source -x and compile it. 

Best, 
Gert 

Bug#829208: RFS: evil-paredit-el/0.0.2-1 ITP

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "evil-paredit-el"

* Package name: evil-paredit-el
  Version : 0.0.2-1
  Upstream Author : Roman Gonzalez 
* Url : https://github.com/roman/evil-paredit
* Licenses: MIT
  Section : lisp

It builds those binary packages:

elpa-evil-paredit -- emacs extension, integrating evil and paredit

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

http://mentors.debian.net/package/evil-paredit-el

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


http://mentors.debian.net/debian/pool/main/e/evil-paredit-el/evil-paredit-el_0.0.2-1.dsc

Alternatively, you can access package debian/ directory via git from URL:

https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-paredit-el.git

More information about evil-paredit-el can be obtained from 
https://github.com/roman/evil-paredit

Changes since last upload:

  * Initial release (Closes: #829207)

Regards,
  Dmitry Bogatov

Bug#829209: cypher-lint: colourise improvements

[Paul Wise]

Package: cypher-lint
Version: 0.3.3-1
Severity: wishlist

The manual page doesn't mention that cypher-lint will automatically
colourise output on terminals but the code does that:

https://sources.debian.net/src/libcypher-parser/latest/src/bin/cypher-lint.c#L104

It would be useful to have a --no-colorize option for people who don't
like colour on their terminal.

It would be useful to have --colourise and --no-colourise options for
people who aren't from the USA.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages cypher-lint depends on:
ii  libc6  2.22-11
ii  libcypher-parser3  0.3.3-1

cypher-lint recommends no packages.

cypher-lint suggests no packages.

-- no debconf information

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#829210: RM: netenv -- RoQA; orphaned; does not work with default init

[Christian Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

netenv has been orphaned since Jun 5 2015 (#787797), has not seen
an upload since 2013-01 and currently does not work with the default
init (systemd) bcause of #739190 (and related, #796639).

Please consider removing the package from unstable.

Thanks,
Christian (wearing no particular hat)

Bug#771303: Add JPEG-XR

[Christoph Biedl]

tags 771303 confirmed upstream moreinfo
thanks

Mathieu Malaterre wrote...

> It would be nice to add support for JPEG-XR file. For instance:
> 
> $ wget -O test.jxr http://phpied.com/files/jpeg-xr/sunset-paint.wdp
> $ file test.jxr
> test.jxr: data

Sorry for not getting back to you earlier. So ...

> According to:
> http://www.itu.int/rec/T-REC-T.832-201201-I/en
> 
> the header is defined with:
> 
> A.5.2 FIXED_FILE_HEADER_II_2BYTES
> FIXED_FILE_HEADER_II_2BYTES shall be equal to 0x4949.
> A.5.3 FIXED_FILE_HEADER_0XBC_BYTE
> FIXED_FILE_HEADER_0XBC_BYTE shall be equal to 0xBC.

... I'm a bit reluctant here since 24 Bits of information is pretty
small and might lead to false detections. Assuming you have a bigger
collection of these files at hand: Can you confirm the version numer
(byte at offset 3) is always 0x01? Also it seems the 32bit
little-endian value at offset 4 has a very limited set of legal
values, too ("multiple of two"); which values are around in the wild?

Christoph


signature.asc
Description: Digital signature

Bug#829211: cypher-lint: better input options

[Paul Wise]

Package: cypher-lint
Version: 0.3.3-1
Severity: wishlist
Control: affects -1 + check-all-the-things
User: check-all-the-things
Usertags: new-check

It would be useful if one could pass multiple filenames to cypher-lint
instead of having to pass it the data on stdin.

It would be useful if cypher-lint could recursively search the current
directory for files to check instead of having to feed data on stding
or filename arguments to it.

Either of these would make it easier to automatically run cypher-lint
from other tools like the check-all-the-things tool.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages cypher-lint depends on:
ii  libc6  2.22-11
ii  libcypher-parser3  0.3.3-1

cypher-lint recommends no packages.

cypher-lint suggests no packages.

-- no debconf information

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#829212: cypher-lint: --version output says neo4j-lint instead of cypher-lint

[Paul Wise]

Package: cypher-lint
Version: 0.3.3-1
Severity: minor

The cypher-lint --version output says neo4j-lint instead of cypher-lint:

$ cypher-lint --version
neo4j-lint: 0.3.3
libcypher-parser: 0.3.3

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages cypher-lint depends on:
ii  libc6  2.22-11
ii  libcypher-parser3  0.3.3-1

cypher-lint recommends no packages.

cypher-lint suggests no packages.

-- no debconf information

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#829213: Backport ansible 2.1.0 to jessie-backports

[Matthew Mosesohn]

Package: ansible
Version: 2.1.0.0-1

Version 2.1.0 is available now for sid, but Jessie has only 2.0.2
available in backports.

Bug#829214: Please enable to specify package repo with Debian version like "Debian8"

[Hideki Yamane]

Package: ftp.debian.org
Severity: wishlist

Hi,

 Package repository's README (e.g. http://ftp.debian.org/debian/README ) says   

> This directory, dists, is the canonical way to access the distributions.
> Each distribution can be accessed by name or state from here.
> 
> oldstable, or wheezy   - the released Debian 7.11
> stable, or jessie  - the released Debian 8.5
> ...

$ cat /etc/apt/sources.list
deb http://ftp.jp.debian.org/debian/ jessie main contrib non-free


How about to be enabled to specify it as 
> oldstable, wheezy or Debian7   - the released Debian 7.11
> stable, jessie or Debian8  - the released Debian 8.5

$ cat /etc/apt/sources.list
deb http://ftp.jp.debian.org/debian/ Debian8 main contrib non-free



Pros)
- It's more easier to understand which version we're using now.
 (sometimes people forget which codename is which version ;)

Cons)
- need changes to code (I don't know it's much or not)
- ?



-- 
Hideki Yamane 

Bug#829215: opam: FTBFS on hurd ("lockf" failed: Operation not supported)

[Ralf Treinen]

Source: opam
Version: 1.2.2-5

Hello, opam fails to compile on hurd-i386 [1]:

Fatal error:
# opam-version1.2.2
# os  unix
/«PKGBUILDDIR»/src/opam: "lockf" failed: Operation not supported
Backtrace:
  Called from file "core/opamSystem.ml", line 619, characters 2-8
  Called from file "core/opamFilename.ml", line 322, characters 13-52
  Called from file "client/opamArg.ml", line 1301, characters 4-53
Makefile:97: recipe for target 'upload' failed
make[4]: *** [upload] Error 1
make[4]: Leaving directory '/«PKGBUILDDIR»/tests'

(apparently during make tests local)

-Ralf.

[1]
https://buildd.debian.org/status/fetch.php?pkg=opam&arch=hurd-i386&ver=1.2.2-5&stamp=1458386255

Bug#829216: ITP: r-cran-shinybs -- GNU R Twitter bootstrap components for Shiny

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-shinybs
  Version : 0.61
  Upstream Author : Eric Bailey 
* URL : https://cran.r-project.org/web/packages/shinyBS
* License : GPL
  Programming Lang: GNU R
  Description : GNU R Twitter bootstrap components for Shiny
 This GNU R package adds additional Twitter Bootstrap components to Shiny.
 .
 Shiny is a GNU R web application framework.


Remark: This package belongs to a pyramid of dependencies of r-cran-treescape
and will be maintained by the Debian Med team at
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-shinybs/trunk/

Bug#829217: RFP: flannel -- flannel is an etcd backed network fabric for containers

[André Cruz]

Package: wnpp
Severity: wishlist

flannel is a virtual network that gives a subnet to each host for use with 
container runtimes.

Platforms like Google's Kubernetes assume that each container (pod) has a 
unique, routable IP inside the cluster. The advantage of this model is that it 
reduces the complexity of doing port mapping.

https://github.com/coreos/flannel