Bug#836940: [buildd-tools-devel] Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[Johannes Schauer]

Hi,

Quoting Thorsten Glaser (2016-09-07 22:53:37)
> Markus Koschany dixit:
> 
> >I have just created a new cowbuilder base chroot with
> >
> >sudo DIST=sid ARCH=amd64 cowbuilder --create
> >
> >and this command still installs gnupg. I don't know what I'm currently
> >missing
> 
> --variant=minbase or --variant=buildd (minbase+build-essential)

as we are talking about testing packages in the most minimal environment
possible it must be noted that debootstrap --variant=minbase or
--variant=buildd does not only install Essential:yes or Essential:yes with
build-essential, respectively, (and their transitive dependencies of course)
but also Priority:required packages like lsb-base or tzdata which are not
depended upon by any Essential:yes package.

Thus, with the current situation, there could exist many source packages that
should explicitly build-depend on Priority:required packages but don't and were
never found so far because all build chroots created by debootstrap include
these packages already.

Maybe a bug against debootstrap is in order that adds a new variant allowing it
to create a more minimal chroot?

Personally, I so far used multistrap to create my chroots, which doesn't suffer
from this problem.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#831673: bug#24024: grep: Mixing "max-count" and "after-context" outputs too few lines

[Paul Eggert]

Given after-context=3 it is expected to output at least 4 lines
as documented, but adding max-count=1 makes it stop on the next
matching line.


Thanks for reporting this. Although grep's behavior is documented ("context does 
not include matching lines" in the node General Output Control) the 
documentation could be clearer and I installed the attached patch.
From 90a2dd8b7f93ef0a8f08741e6fcb07220f9549f6 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 7 Sep 2016 22:22:37 -0700
Subject: [PATCH] doc: define "context lines"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Reported by Igor Bogomazov via Santiago Ruano Rincón (Bug#24024).
* doc/grep.texi (Context Line Control): Define "context lines".
---
 doc/grep.texi | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/grep.texi b/doc/grep.texi
index 80768dd..7e51d45 100644
--- a/doc/grep.texi
+++ b/doc/grep.texi
@@ -338,6 +338,7 @@ do
 done
 @end example
 
+@cindex context lines
 When @command{grep} stops after @var{num} matching lines,
 it outputs any trailing context lines.
 Since context does not include matching lines,
@@ -501,8 +502,11 @@ even those that contain newline characters.
 @node Context Line Control
 @subsection Context Line Control
 
+@cindex context lines
+@dfn{Context lines} are non-matching lines that are near a matching line.
+They are output only if one of the following options are used.
 Regardless of how these options are set,
-@command{grep} will never print any given line more than once.
+@command{grep} never outputs any given line more than once.
 If the @option{-o} (@option{--only-matching}) option is specified,
 these options have no effect and a warning is given upon their use.
 
@@ -530,7 +534,7 @@ Print @var{num} lines of leading context before matching 
lines.
 @opindex -C
 @opindex --context
 @opindex -@var{num}
-@cindex context
+@cindex context lines
 Print @var{num} lines of leading and trailing output context.
 
 @item --group-separator=@var{string}
-- 
2.7.4

Bug#837040: RFS: btrfs-progs/4.7.2-0.1 [RC NMU]

[Nicholas D Steeves]

Control: retitle -1 'RFS: btrfs-progs/4.7.2-0.1 [RC NMU]'

Was almost asleep and then realised this; here is the correct link:
 dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.7.2-0.1.dsc

Humble regards,
Nicholas


signature.asc
Description: Digital signature

Bug#836805: [pkg-go] Bug#836805: gobgp: FTBFS (i386): undefined: syscall.SYS_SETSOCKOPT

[Vincent Bernat]

 ❦  6 septembre 2016 02:42 CEST, "Aaron M. Ucko"  :

> The i386 build of gobgp failed:
>
>   # github.com/osrg/gobgp/server
>   src/github.com/osrg/gobgp/server/sockopt.go:66: undefined: 
> syscall.SYS_SETSOCKOPT
>   src/github.com/osrg/gobgp/server/sockopt_linux.go:95: undefined: 
> syscall.SYS_SETSOCKOPT
>
> AFAICT, this error stems from the fact that early Linux architectures such
> as i386 historically multiplexed setsockopt and several other functions
> through a special "socketcall" syscall.  i386 did eventually develop a
> dedicated setsockopt syscall (number 366), but zsysnum_linux_386.go
> doesn't (yet) reflect that, and I don't know what the runtime portability
> considerations of using it would be anyway.  Instead, I'd recommend using
> the predefined syscall.setsockopt wrapper.
>
> Could you please take a look?

Unfortunately, the wrapper is not available to use by external
packages. The syscall.SetsockoptString could be used instead since Go
strings are not null-terminated.
-- 
Use statement labels that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#837042: libtomcrypt: CVE-2016-6129

[Salvatore Bonaccorso]

Source: libtomcrypt
Version: 1.17-6
Severity: important
Tags: security upstream patch

Hi,

the following vulnerability was published for libtomcrypt.

CVE-2016-6129[0]:
possible bleichenbacher signature attack 

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6129
[1] 
https://github.com/libtom/libtomcrypt/commit/5eb9743410ce4657e9d54fef26a2ee31a1b5dd09

Regards,
Salvatore

Bug#837040: RFS: btrfs-progs/4.7.1-1~bpo8+1 [RC NMU]

[Nicholas D Steeves]

On Thu, Sep 08, 2016 at 07:11:31AM +0200, Adam Borowski wrote:
> On Thu, Sep 08, 2016 at 12:57:32AM -0400, Nicholas D Steeves wrote:
> > Package: sponsorship-requests
> > Severity: grave
> > 
> > I am looking for a sponsor for an urgent NMU of "btrfs-progs".  Upstream
> > has marked this as an "urgent fix" <
> > https://btrfs.wiki.kernel.org/index.php/Changelog#btrfs-progs-4.7.2_.28Sep_2016.29
> 
> > Package name: btrfs-progs
> > Version : 4.7.1-1~bpo8+1
> 
> Except, you see, it's 4.7 and 4.7.1 which are the buggy versions, 4.6.1 is
> unaffected.  So you demand, with a grave severity, to overwrite a known-good
> version with one with a data loss bug.
> 
> -- 
> Second "wet cat laying down on a powered on box-less SoC on the desk" close
> shave in a week.  Protect your ARMs, folks!

I hit "r" instead of "g", so my last reply didn't make it to the bug-tracker.  
This is an error in my bug submission, and I am embarassed I made that mistake 
(too late here, I'm going to sleep).  It should read:

Package name: btrfs-progs
Version : 4.7.2-0.1

5 Sept (I think, it might have been earlier) I asked Gianfranco to cancel my 
bpo in the deferred queue because of this issue.

Thank you,
Nicholas


signature.asc
Description: Digital signature

Bug#837043: nim: Nimble is not packaged

[Russel Winder]

Package: nim
Version: 0.14.2-1
Severity: normal

Dear Maintainer,

The nim package provides the compiler and stuff, but the nimble system is not 
provided, perhaps this should
be a separate package?


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/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 nim depends on:
ii  libc6  2.24-1

nim recommends no packages.

nim suggests no packages.

-- no debconf information

Bug#780881: mutt: tls_socket_read (A TLS packet with unexpected length was received.)

[Antonio Radici]

Control: tag -1 +moreinfo

On Fri, Mar 20, 2015 at 11:05:36PM +0100, Axel Stammler wrote:
> 
> Dear Maintainer,
> 
> - Mutt can access other IMAPS servers without problems.
> - This server (imaps://***@versanet...@mail-ssl.versatel.de/) can be accessed 
> without
>   problems using Evolution.
> - Mutt reports the error quoted on the Subject line earlier or later while 
> communicating
>   with the server, sometimes after asking for the password, sometimes 
> rightaway before
>   that.

This should be fixed in 1.7.0-1, please let us know if that's not the case. I'll
leave it tagged moreinfo for 1 week.

Bug#837040: RFS: btrfs-progs/4.7.1-1~bpo8+1 [RC NMU]

[Adam Borowski]

On Thu, Sep 08, 2016 at 12:57:32AM -0400, Nicholas D Steeves wrote:
> Package: sponsorship-requests
> Severity: grave
> 
> I am looking for a sponsor for an urgent NMU of "btrfs-progs".  Upstream
> has marked this as an "urgent fix" <
> https://btrfs.wiki.kernel.org/index.php/Changelog#btrfs-progs-4.7.2_.28Sep_2016.29

> Package name: btrfs-progs
> Version : 4.7.1-1~bpo8+1

Except, you see, it's 4.7 and 4.7.1 which are the buggy versions, 4.6.1 is
unaffected.  So you demand, with a grave severity, to overwrite a known-good
version with one with a data loss bug.

-- 
Second "wet cat laying down on a powered on box-less SoC on the desk" close
shave in a week.  Protect your ARMs, folks!

Bug#837040: RFS: btrfs-progs/4.7.1-1~bpo8+1 [RC NMU]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: grave

Dear mentors,

I am looking for a sponsor for an urgent NMU of "btrfs-progs".  Upstream has 
marked this as an "urgent fix" < 
https://btrfs.wiki.kernel.org/index.php/Changelog#btrfs-progs-4.7.2_.28Sep_2016.29
 >

Sept 5th I filed bug #836778 notifying the maintainer of the issue.

Package name: btrfs-progs
Version : 4.7.1-1~bpo8+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.7.1-1~bpo8+1.dsc

It is also available here:

  https://github.com/sten0/btrfs-progs.git

Changes since the last upload:

   * Non-maintainer upload.
   * New upstream release. (Closes #836778)

Regards,
Nicholas


signature.asc
Description: Digital signature

Bug#837039: firefox-esr: random crash (SIGSEGV)

[Paul Wise]

Package: firefox-esr
Version: 45.3.0esr-1
Severity: normal

I got a random crash (SIGSEGV) in firefox-esr. If the below backtrace
and the attached full backtrace aren't useful, please close this bug.

Core was generated by `firefox-esr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:58
58  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f7cd0dff700 (LWP 4762))]
#0  0x7f7cf869cfdf in raise (sig=sig@entry=11) at 
../sysdeps/unix/sysv/linux/raise.c:58
#1  0x7f7cf485a75f in nsProfileLock::FatalSignalHandler(int, siginfo_t*, 
void*) (signo=11, info=0x7f7cd0dfe370, context=0x7f7cd0dfe240) at 
/tmp/buildd/firefox-esr-45.3.0esr/toolkit/profile/nsProfileLock.cpp:185
#2  0x7f7cf515cde1 in AsmJSFaultHandler(int, siginfo_t*, void*) 
(signum=, info=0x7f7cd0dfe370, context=0x7f7cd0dfe240) at 
/tmp/buildd/firefox-esr-45.3.0esr/js/src/asmjs/AsmJSSignalHandlers.cpp:1159
#3  0x7f7cf869d100 in  () at 
/lib/x86_64-linux-gnu/libpthread.so.0
#4  0x7f7cf4e617d3 in JS_AbortIfWrongThread(JSRuntime*) (rt=0x7f7cd3c1a000) 
at /tmp/buildd/firefox-esr-45.3.0esr/js/src/jsapi.cpp:5821
#5  0x7f7cf4ea766e in js::gc::GCRuntime::collect(bool, js::SliceBudget, 
JS::gcreason::Reason) (this=0x7f7cd3c1a3f8) at 
/tmp/buildd/firefox-esr-45.3.0esr/js/src/jsgc.cpp:6340
#6  0x7f7cf4ea766e in js::gc::GCRuntime::collect(bool, js::SliceBudget, 
JS::gcreason::Reason) (this=this@entry=0x7f7cd3c1a3f8, 
nonincrementalByAPI=nonincrementalByAPI@entry=true, budget=..., 
reason=reason@entry=JS::gcreason::DOM_WORKER) at 
/tmp/buildd/firefox-esr-45.3.0esr/js/src/jsgc.cpp:6369
#7  0x7f7cf4ea9410 in JS::GCForReason(JSRuntime*, JSGCInvocationKind, 
JS::gcreason::Reason) (reason=JS::gcreason::DOM_WORKER, gckind=GC_SHRINK, 
this=0x7f7cd3c1a3f8) at /tmp/buildd/firefox-esr-45.3.0esr/js/src/jsgc.cpp:6442
#8  0x7f7cf4ea9410 in JS::GCForReason(JSRuntime*, JSGCInvocationKind, 
JS::gcreason::Reason) (rt=rt@entry=0x7f7cd3c1a000, 
gckind=gckind@entry=GC_SHRINK, reason=reason@entry=JS::gcreason::DOM_WORKER) at 
/tmp/buildd/firefox-esr-45.3.0esr/js/src/jsgc.cpp:7340
#9  0x7f7cf4154736 in 
mozilla::dom::workers::WorkerPrivate::GarbageCollectInternal(JSContext*, bool, 
bool) (this=0x7f7ccc331800, aCx=0x7f7ccbf67c00, aShrinking=true, 
aCollectChildren=) at 
/tmp/buildd/firefox-esr-45.3.0esr/dom/workers/WorkerPrivate.cpp:6251
#10 0x7f7cf4154822 in (anonymous 
namespace)::GarbageCollectRunnable::WorkerRun(JSContext*, 
mozilla::dom::workers::WorkerPrivate*) (this=, aCx=, aWorkerPrivate=) at 
/tmp/buildd/firefox-esr-45.3.0esr/dom/workers/WorkerPrivate.cpp:1480
#11 0x7f7cf4158dc1 in mozilla::dom::workers::WorkerRunnable::Run() 
(this=0x7f7cd2fcd790) at 
/tmp/buildd/firefox-esr-45.3.0esr/dom/workers/WorkerRunnable.cpp:360
#12 0x7f7cf4167899 in 
mozilla::dom::workers::WorkerPrivate::ProcessAllControlRunnablesLocked() 
(this=this@entry=0x7f7ccc331800) at 
/tmp/buildd/firefox-esr-45.3.0esr/dom/workers/WorkerPrivate.cpp:4995
#13 0x7f7cf4169556 in 
mozilla::dom::workers::WorkerPrivate::DoRunLoop(JSContext*) 
(this=0x7f7ccc331800, aCx=aCx@entry=0x7f7ccbf67c00) at 
/tmp/buildd/firefox-esr-45.3.0esr/dom/workers/WorkerPrivate.cpp:4460
#14 0x7f7cf413a306 in (anonymous 
namespace)::WorkerThreadPrimaryRunnable::Run() (this=0x7f7ccdca0d90) at 
/tmp/buildd/firefox-esr-45.3.0esr/dom/workers/RuntimeService.cpp:2722
#15 0x7f7cf308c9de in nsThread::ProcessNextEvent(bool, bool*) 
(this=0x7f7cd691a100, aMayWait=, aResult=0x7f7cd0dfedd7) at 
/tmp/buildd/firefox-esr-45.3.0esr/xpcom/threads/nsThread.cpp:972
#16 0x7f7cf30a838d in NS_ProcessNextEvent(nsIThread*, bool) 
(aThread=, aMayWait=aMayWait@entry=false) at 
/tmp/buildd/firefox-esr-45.3.0esr/xpcom/glue/nsThreadUtils.cpp:297
#17 0x7f7cf3288311 in 
mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 
(this=0x7f7ccfbe1400, aDelegate=0x7f7ccc050ae0) at 
/tmp/buildd/firefox-esr-45.3.0esr/ipc/glue/MessagePump.cpp:326
#18 0x7f7cf32785ae in MessageLoop::Run() (this=) at 
/tmp/buildd/firefox-esr-45.3.0esr/ipc/chromium/src/base/message_loop.cc:227
#19 0x7f7cf32785ae in MessageLoop::Run() (this=this@entry=0x7f7ccc050ae0) 
at /tmp/buildd/firefox-esr-45.3.0esr/ipc/chromium/src/base/message_loop.cc:201
#20 0x7f7cf308fc4a in nsThread::ThreadFunc(void*) (aArg=0x7f7cd691a100) at 
/tmp/buildd/firefox-esr-45.3.0esr/xpcom/threads/nsThread.cpp:376
#21 0x7f7cf1e32758 in _pt_root (arg=0x7f7cd662c220) at ptthread.c:216
#22 0x7f7cf8693464 in start_thread (arg=0x7f7cd0dff700) at 
pthread_create.c:333
#23 0x7f7cf793797f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

-- 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, 

Bug#836618: ccd2iso: please drop the build dependency on hardening-wrapper

[Asheesh Laroia]

Thanks. Will do.

Bug#837030: gdk-pixbuf: FTBFS on most architectures due to test failures

[Michael Biebl]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=771026

We've already seen the issue and forwarded to upstream.

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



signature.asc
Description: OpenPGP digital signature

Bug#833054: e2fsprogs: fsck.ext4 does not repair filesystem

[Theodore Ts'o]

On Wed, Sep 07, 2016 at 10:21:34PM +0100, ael wrote:
> Of course, I can just reformat the card, and I am confident that it will
> then work, but this looks like an opportunity to uncover a "feature"
> lurking somewhere. I imagine that you will ask for an dumpe2fs run next?

Actually, what I'd like is a compressed e2image dump of the file
system, and reproduction instructions so I can try to replicate the
problem in an environment where I can observe it.

See "man e2image" and look for the section for RAW IMAGE FILES for
more details.  This will allow you to send me just the metadata of the
file (so I won't see any of the data blocks), but that should be
enough to replicate the problem.  It would leak out the directory
names to me, which might or might not be an issue that you would be
concerned about.

There is a "scramble" option which will scramble the filenames, but
that will screw up the htree directory structures, so I'd prefer not
having the filename unless you feel strongly about the filenames being
privacy sensitive --- in which case an e2image with scrambled
filenames is better than nothing.

Cheers,

- Ted

Bug#837031: libgtk-3-0: Inconsistent double click behaviour in file chooser

[Fabián Inostroza]

It has already been reported, I forgot to add links. I hope they fix this
problem but maybe would be faster to use the Ubuntu patch.

https://bugzilla.gnome.org/show_bug.cgi?id=766089
https://bugzilla.gnome.org/show_bug.cgi?id=758065

2016-09-07 21:12 GMT-03:00 D. B. :

> As a fellow user I would request that you file this bug upstream so that
> GTK+ are aware of how annoying it is, if no one has already filed such a
> ticket (I could not find one on an extremely brief search)
>
> This annoyance is not debian specific, so why (A) burden the deb
> maintainers, (B) not make GTK+ aware of the annoyance, (C) exclude other
> distro users, etc.
>
>
> On Thu, Sep 8, 2016 at 12:57 AM, Fabián Inostroza <
> soulsonceonf...@gmail.com> wrote:
>
>> Package: libgtk-3-0
>> Version: 3.21.5-3
>> Severity: important
>>
>> Dear Maintainer,
>>
>> In recent versions of gtk3 the double click behaviour of the file chooser
>> dialog got inconsistent.
>> Basically sometimes, when a folder is already selected, a single click
>> opens that folder.
>>
>> See [1] for more information and a patch.
>>
>> [1]: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1519778
>>
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages libgtk-3-0 depends on:
>> ii  adwaita-icon-theme  3.20-3
>> ii  hicolor-icon-theme  0.15-1
>> ii  libatk-bridge2.0-0  2.20.1-4
>> ii  libatk1.0-0 2.20.0-1
>> ii  libc6   2.23-5
>> ii  libcairo-gobject2   1.14.6-1+b1
>> ii  libcairo2   1.14.6-1+b1
>> ii  libcolord2  1.3.2-1
>> ii  libcups22.1.4-4
>> ii  libepoxy0   1.3.1-1
>> ii  libfontconfig1  2.11.0-6.7
>> ii  libfreetype62.6.3-3+b1
>> ii  libgdk-pixbuf2.0-0  2.34.0-1
>> ii  libglib2.0-02.49.6-1
>> ii  libgtk-3-common 3.21.5-3
>> ii  libjson-glib-1.0-0  1.2.2-1
>> ii  libpango-1.0-0  1.40.2-1
>> ii  libpangocairo-1.0-0 1.40.2-1
>> ii  libpangoft2-1.0-0   1.40.2-1
>> ii  librest-0.7-0   0.8.0-1
>> ii  libsoup2.4-12.55.90-1
>> ii  libwayland-client0  1.11.0-2
>> ii  libwayland-cursor0  1.11.0-2
>> ii  libwayland-egl1-mesa [libwayland-egl1]  11.2.2-1
>> ii  libx11-62:1.6.3-1
>> ii  libxcomposite1  1:0.4.4-1
>> ii  libxcursor1 1:1.1.14-1+b1
>> ii  libxdamage1 1:1.1.4-2+b1
>> ii  libxext62:1.3.3-1
>> ii  libxfixes3  1:5.0.2-1
>> ii  libxi6  2:1.7.6-1
>> ii  libxinerama12:1.1.3-1+b1
>> ii  libxkbcommon0   0.6.1-1
>> ii  libxml2 2.9.4+dfsg1-1+b1
>> ii  libxrandr2  2:1.5.0-1
>> ii  shared-mime-info1.6-1
>>
>> Versions of packages libgtk-3-0 recommends:
>> ii  libgtk-3-bin  3.21.5-3
>>
>> Versions of packages libgtk-3-0 suggests:
>> ii  gvfs 1.29.91-1
>> ii  librsvg2-common  2.40.16-1
>>
>> -- no debconf information
>>
>>
>

Bug#837038: dput-ng: Please add hook to check if orig tarball is included

[Jeremy Bicha]

Package: dput-ng
Version: 1.10
Severity: wishlist

Uploads to mentors.debian.net currently require the original tarball
be included, even for packages where the original tarball is already
in Debian.

It would be nice if dput would automatically warn the uploader about
this instead of the uploader having to wait to get a rejection email
to learn about this policy.

Thanks,
Jeremy Bicha

Bug#832077: Info received (emacs clutter screen on windows switch)

[Leon Meier]

By the way, I don't know who is the culprit: libgtk-3-0, emacs, or 
someone else. So please consider my found / nofound tags just as 
additional information on my configuration rather as a bug source hint. 
Sorry about that.

Bug#832077: emacs clutter screen on windows switch

[Leon Meier]

found 832077 libgtk-3-0/3.21.5-3
thanks

Bug#837037: libcmrt: FTBFS on x32: invalid instruction suffix for `push'/`pop'

[Aaron M. Ucko]

Source: libcmrt
Version: 1.0.5+git20160516.dfsg1-1
Severity: important
Justification: fails to build from source

The x32 build of libcmrt failed:

  ../../src/cm_mem.h: Assembler messages:
  ../../src/cm_mem.h:192: Error: invalid instruction suffix for `push'
  ../../src/cm_mem.h:195: Error: invalid instruction suffix for `pop'
  Makefile:852: recipe for target 'libcmrt_la-cm_buffer.lo' failed
  make[4]: *** [libcmrt_la-cm_buffer.lo] Error 1

Please rework this code to use __get_cpuid from .  It would
be great if you could also check for other breakage, but x32 is an
experimental architecture with no porterbox.  (You might still be able
to set up a chroot or cross-building environment, though.)

Thanks!

Bug#837036: gitolite3: uninstallable without . in @INC

[David Bremner]

Package: gitolite3
Version: 3.6.4-1
Severity: serious
Tags: upstream
Justification: uninstallable
User: debian-p...@lists.debian.org
Usertags: perl-cwd-inc-removal

The package fails to configure with the new default settings for @INC.

This is fixed in upstream commit 35e0b2a. Rather than cherry-picking
that, I'm planning to wait for a new upstream release, which should be
less than a week.


Setting up gitolite3 (3.6.4-1) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
Configuring gitolite3
-

Please specify the key of the user that will administer the access 
configuration of gitolite.

This can be either the SSH public key itself, or the path to a file containing 
it. If it is blank, gitolite will 
be left unconfigured and must be set up manually.

If migrating from gitolite version 2.x, leave this blank.

Administrator's SSH key: /tmp/bremner.pub


Initialized empty Git repository in 
/var/lib/gitolite3/repositories/gitolite-admin.git/
Initialized empty Git repository in /var/lib/gitolite3/repositories/testing.git/
FATAL: parse 'conf/gitolite.conf-compiled.pm' failed: No such file or directory
dpkg: error processing package gitolite3 (--configure):


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

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

Versions of packages gitolite3 depends on:
ii  adduser  3.115
ii  debconf [debconf-2.0]1.5.59
ii  git [git-core]   1:2.9.3-1
ii  libjson-perl 2.90-1
ii  openssh-server [ssh-server]  1:7.3p1-1
ii  perl 5.22.2-3

gitolite3 recommends no packages.

Versions of packages gitolite3 suggests:
pn  git-daemon-sysvinit  
pn  gitweb   

-- debconf information:
  gitolite3/gitdir: /var/lib/gitolite3
* gitolite3/adminkey:
  gitolite3/gituser: gitolite3

Bug#836426: Caused by libgtk-3-0 3.21

[Josh Triplett]

On Thu, Sep 08, 2016 at 02:24:37AM +0200, Michael Biebl wrote:
> On Wed, 7 Sep 2016 09:21:55 -0700 Josh Triplett 
> wrote:
> > Control: reassign -1 libgtk-3-0 3.21.5-3
> > Control: affects -1 gnome-boxes
> > Control: severity -1 serious
> > Control: forcemerge -1 832077
> 
> To me those two issues look not like they are related.
> 
> After all, this one was file for 3.20, the other one for 3.21.

Both bugs were filed for libgtk-3-0 3.21.  (836426 was originally filed
on gnome-boxes 3.20 but running with libgtk-3-0 3.21, and I can confirm
that the issue disappears when downgrading to libgtk-3-0 3.20 and
reappears when upgrading to libgtk-3-0 3.21.  All three mails in 832077
specifically mentioned libgtk-3-0 3.21.)  None of the reports apply to
libgtk-3-0 3.20.

I changed the applicable version number when reassigning to libgtk-3-0,
and as far as I can tell that did update the BTS metadata correctly.

> The severity seems overinflated as well.

It seems appropriate for an issue that causes window contents to fail to
render, making gnome-boxes unusable with that version of GTK+.  It also
seems appropriate for what looks like a backwards-compatibility issue in
GTK+.  "serious" seems appropriate for "this shouldn't get released in
the next stable release".

Bug#832077: emacs clutter screen on windows switch

[Leon Meier]

found 832077 emacs/46.1
thanks

The message

(emacs:6144): Gtk-WARNING **: GtkWindow 0xc50270 is drawn without a 
current allocation. This should not happen.


is printed to xterm from where emacs was started. Printing happens  when 
the emacs window gets the focus due to a left-button mouse click.


For me, it's not a huge trouble, but still, annoying.

Bug#837035: libcmrt: please restrict architecture to x86

[Aaron M. Ucko]

Source: libcmrt
Version: 1.0.5+git20160516.dfsg1-1
Severity: important
Justification: fails to build from source

Thanks for promptly taking care of #836879/#836971.  However, I see
that builds of libcmrt for most architectures are still failing.  One
issue there is that it naturally doesn't support non-x86 platforms.
As such, please declare

Architecture: any-amd64 any-i386 x32

so non-x86 autobuilders won't bother trying to cover it.  (any-x32
would be equivalent to x32, and its usage apparently yields a
warning.)  Yes, the only successful builds were for amd64 and i386,
but the non-Linux builds failed as a side effect of libdrm bug
#837034, and I expect the x32 failure (which I'll report separately)
should also be addressable.

Thanks!

Bug#837034: libdrm: FTBFS on non-Linux: drm.h: bad #include choices

[Aaron M. Ucko]

Source: libdrm
Version: 2.4.70-1
Severity: important
Justification: fails to build from source (but built successfully in the past)

Builds of libdrm on kFreeBSD and the Hurd have been failing because
the headers drm.h pulls in on those platforms don't work out.
Specifically, kFreeBSD builds have been failing with

  In file included from ../../../include/drm/drm_fourcc.h:27:0,
   from ../../../tests/kms/libkms-test-framebuffer.c:33:
  ../../../include/drm/drm.h:50:9: error: unknown type name 'uint8_t'
   typedef uint8_t  __u8;
   ^
  ../../../include/drm/drm.h:52:9: error: unknown type name 'uint16_t'
   typedef uint16_t __u16;
   ^
  ../../../include/drm/drm.h:54:9: error: unknown type name 'uint32_t'
   typedef uint32_t __u32;
   ^
  ../../../include/drm/drm.h:56:9: error: unknown type name 'uint64_t'
   typedef uint64_t __u64;
   ^

and Hurd builds have been failing with

  In file included from ../xf86drm.h:40:0,
   from ../xf86drm.c:70:
  ../include/drm/drm.h:47:24: fatal error: sys/ioccom.h: No such file or 
directory

To remedy these errors, I would recommend replacing  with
 (which is more broadly available, and pulls in
 on both kFreeBSD/GNU and pure *BSD), and supplementing
 with .  ( should stay for size_t.)

Could you please take a look?

Thanks!

Bug#837033: RM: linux-tools -- ROM; replaced by linux source package

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal

All binary packages previously built by src:linux-tools have been
taken over by src:linux (modulo changes to version numbers in their
names).

Please take care to only close bugs assigned to src:linux-tools (there
should only be one, #837015) and not to the binary packages.

Ben.

Bug#836442: midori: cannot open local HTML files

[Vincent Lefevre]

On 2016-09-07 19:32:48 -0400, Sergio Durigan Junior wrote:
> This is strange.  I do not have this file, and I have the
> shared-mime-info package installed.

All the files in .local/share/mime were created on
2015-09-10 01:24:02. I couldn't find anything interesting
in the history.

> I tried to create this file on my $HOME, but I still can't reproduce
> the bug. Can you please try to temporarily remove the file and see
> if it fixes the problem?

The problem disappears after renaming this "mime" directory.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#836426: Caused by libgtk-3-0 3.21

[Michael Biebl]

On Wed, 7 Sep 2016 09:21:55 -0700 Josh Triplett 
wrote:
> Control: reassign -1 libgtk-3-0 3.21.5-3
> Control: affects -1 gnome-boxes
> Control: severity -1 serious
> Control: forcemerge -1 832077

To me those two issues look not like they are related.

After all, this one was file for 3.20, the other one for 3.21.

The severity seems overinflated as well.

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



signature.asc
Description: OpenPGP digital signature

Bug#837013: notmuch: FTBFS: Tests failures

[David Bremner]

Lucas Nussbaum  writes:

> Source: notmuch
> Version: 0.22.1-3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160906 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
>
> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2016/09/06/notmuch_0.22.1-3_unstable.log

It doesn't seem to be there?

In any case I think I can reproduce at least some of the failures
locally; it seems to related to changes in the output of

gpg --no-tty --list-secret-keys --with-colons --fingerprint

introduced by gnupg 2.1.15

The failures I can reproduce are fixed by

diff --git a/test/T350-crypto.sh b/test/T350-crypto.sh
index 3656cce..5a63183 100755
--- a/test/T350-crypto.sh
+++ b/test/T350-crypto.sh
@@ -26,7 +26,7 @@ add_gnupg_home ()
 
 add_gnupg_home
 # get key fingerprint
-FINGERPRINT=$(gpg --no-tty --list-secret-keys --with-colons --fingerprint | 
grep '^fpr:' | cut -d: -f10)
+FINGERPRINT=$(gpg --no-tty --list-secret-keys --with-colons --fingerprint | 
grep '^fpr:' | cut -d: -f10 |head -1)
 
 test_expect_success 'emacs delivery of signed message' \
 'emacs_fcc_message \

I'll have to think about whether this is the most robust fix possible;
I'd like to avoid future breakage caused by gpg changing --with-colons
output.

Bug#837031: libgtk-3-0: Inconsistent double click behaviour in file chooser

[D. B.]

As a fellow user I would request that you file this bug upstream so that
GTK+ are aware of how annoying it is, if no one has already filed such a
ticket (I could not find one on an extremely brief search)

This annoyance is not debian specific, so why (A) burden the deb
maintainers, (B) not make GTK+ aware of the annoyance, (C) exclude other
distro users, etc.


On Thu, Sep 8, 2016 at 12:57 AM, Fabián Inostroza  wrote:

> Package: libgtk-3-0
> Version: 3.21.5-3
> Severity: important
>
> Dear Maintainer,
>
> In recent versions of gtk3 the double click behaviour of the file chooser
> dialog got inconsistent.
> Basically sometimes, when a folder is already selected, a single click
> opens that folder.
>
> See [1] for more information and a patch.
>
> [1]: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1519778
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libgtk-3-0 depends on:
> ii  adwaita-icon-theme  3.20-3
> ii  hicolor-icon-theme  0.15-1
> ii  libatk-bridge2.0-0  2.20.1-4
> ii  libatk1.0-0 2.20.0-1
> ii  libc6   2.23-5
> ii  libcairo-gobject2   1.14.6-1+b1
> ii  libcairo2   1.14.6-1+b1
> ii  libcolord2  1.3.2-1
> ii  libcups22.1.4-4
> ii  libepoxy0   1.3.1-1
> ii  libfontconfig1  2.11.0-6.7
> ii  libfreetype62.6.3-3+b1
> ii  libgdk-pixbuf2.0-0  2.34.0-1
> ii  libglib2.0-02.49.6-1
> ii  libgtk-3-common 3.21.5-3
> ii  libjson-glib-1.0-0  1.2.2-1
> ii  libpango-1.0-0  1.40.2-1
> ii  libpangocairo-1.0-0 1.40.2-1
> ii  libpangoft2-1.0-0   1.40.2-1
> ii  librest-0.7-0   0.8.0-1
> ii  libsoup2.4-12.55.90-1
> ii  libwayland-client0  1.11.0-2
> ii  libwayland-cursor0  1.11.0-2
> ii  libwayland-egl1-mesa [libwayland-egl1]  11.2.2-1
> ii  libx11-62:1.6.3-1
> ii  libxcomposite1  1:0.4.4-1
> ii  libxcursor1 1:1.1.14-1+b1
> ii  libxdamage1 1:1.1.4-2+b1
> ii  libxext62:1.3.3-1
> ii  libxfixes3  1:5.0.2-1
> ii  libxi6  2:1.7.6-1
> ii  libxinerama12:1.1.3-1+b1
> ii  libxkbcommon0   0.6.1-1
> ii  libxml2 2.9.4+dfsg1-1+b1
> ii  libxrandr2  2:1.5.0-1
> ii  shared-mime-info1.6-1
>
> Versions of packages libgtk-3-0 recommends:
> ii  libgtk-3-bin  3.21.5-3
>
> Versions of packages libgtk-3-0 suggests:
> ii  gvfs 1.29.91-1
> ii  librsvg2-common  2.40.16-1
>
> -- no debconf information
>
>

Bug#449603: NMU for lakai

[Gustavo S. L.]

Control: tags 817516 patch
Control: tags 817516 pending
Control: tags 835651 patch
Control: tags 835651 pending
Control: tags 449603 patch
Control: tags 449603 pending
Control: tags 450202 patch
Control: tags 450202 pending

Hi

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

lakai (0.1-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * debian/compat:
  - Update level to 9. (Closes: #817516)
  * debian/control:
  - Added Homepage. (Closes: #835651)
  - Bumped level debhelper to 9.
  - Bumped Standards-Version to 3.9.8.
  * debian/watch:
  - Update. (Closes: #449603, #450202).

I attached a debdiff.

Best regards,

Gustavo Soares de Lima


lakai.debdiff
Description: Binary data

Bug#837032: chromium: unexpected gnome-keyring starts

[Kevin Bradenstein]

Package: chromium
Version: 53.0.2785.92-1
Severity: normal

Dear Maintainer,

everytime I start chromium the gnome-keyring starts.
This behaviour is very annoying, because I am using a tiling window
manager and the gnome-keyring windows captures all input except ESC.

Greetings
Kevin

Bug#837031: libgtk-3-0: Inconsistent double click behaviour in file chooser

[Fabián Inostroza]

Package: libgtk-3-0
Version: 3.21.5-3
Severity: important

Dear Maintainer,

In recent versions of gtk3 the double click behaviour of the file chooser 
dialog got inconsistent.
Basically sometimes, when a folder is already selected, a single click opens 
that folder.

See [1] for more information and a patch.

[1]: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1519778

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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme  3.20-3
ii  hicolor-icon-theme  0.15-1
ii  libatk-bridge2.0-0  2.20.1-4
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.23-5
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcolord2  1.3.2-1
ii  libcups22.1.4-4
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.49.6-1
ii  libgtk-3-common 3.21.5-3
ii  libjson-glib-1.0-0  1.2.2-1
ii  libpango-1.0-0  1.40.2-1
ii  libpangocairo-1.0-0 1.40.2-1
ii  libpangoft2-1.0-0   1.40.2-1
ii  librest-0.7-0   0.8.0-1
ii  libsoup2.4-12.55.90-1
ii  libwayland-client0  1.11.0-2
ii  libwayland-cursor0  1.11.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  11.2.2-1
ii  libx11-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.2-1
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.6.1-1
ii  libxml2 2.9.4+dfsg1-1+b1
ii  libxrandr2  2:1.5.0-1
ii  shared-mime-info1.6-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.21.5-3

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.29.91-1
ii  librsvg2-common  2.40.16-1

-- no debconf information

Bug#834682: mina2: FTBFS in testing (failing tests)

[Santiago Vila]

On Wed, 7 Sep 2016, Markus Koschany wrote:

> I am attaching two build logs (cowbuilder and sbuild) that show no
> issues at all. The build succeeds.

Thanks a lot for trying to reproduce this.

There are still a lot of differences, we should better remove them all,
until our building environments are the same. Then it should fail
for you too (hopefully).

Would you please add this to the mix?:

* Use a stretch chroot (as reported).

* Build only arch-independent packages (as reported).
  This is the equivalent to "dpkg-buildpackage -A".
  In sbuild it's done with options "--arch-all --no-arch-any".

* The chroot should be as small as possible. Well, I don't do exactly
  that because most packages build-depend on debhelper, and I want
  to save disk I/O so I have debhelper by default, but on the other side
  I don't have gnupg installed.
  
  To simplify: Would you please install the packages in
  package-list.txt (attached) and only those?
  
[ This is of course only the starting point, sbuild should then
  automatically download and install the required packages ].

* I'm also using --resolve-alternatives option of sbuild. Don't know if
  it's relevant but we should try to minimize differences. There is at
  least one package that FTBFS if I didn't use this option, which is
  otherwise the default (AFAIK) in the official buildds.

* Build with only one CPU. This is achieved by putting this in .sbuildrc:

$ENV{'DEB_BUILD_OPTIONS'} = 'parallel=1';

* Finally, I'm building on machines with not a lot of memory, because
  monitoring /proc/meminfo tells me that I don't need more for this
  particular package (but maybe I'm wrong).
  
  Please try on a virtual machine having only 1GB RAM and 1 GB swap.


If you do all this, the probability that you will reproduce the bug
may only increase (but of course it may also continue to be zero).
In either case, we should try.

Thanks.adduser
apt
autoconf
automake
autopoint
autotools-dev
base-files
base-passwd
bash
binutils
bsdmainutils
bsdutils
build-essential
bzip2
coreutils
cpp
cpp-6
dash
debconf
debhelper
debian-archive-keyring
debianutils
dh-autoreconf
dh-strip-nondeterminism
diffutils
dmsetup
dpkg
dpkg-dev
e2fslibs
e2fsprogs
eatmydata
fakeroot
file
findutils
g++
g++-6
gcc
gcc-5-base
gcc-6
gcc-6-base
gettext
gettext-base
gpgv
grep
groff-base
gzip
hostname
init-system-helpers
initscripts
insserv
intltool-debian
less
libacl1
libapt-pkg5.0
libarchive-zip-perl
libasan3
libatomic1
libattr1
libaudit-common
libaudit1
libblkid1
libbsd0
libbz2-1.0
libc-bin
libc-dev-bin
libc-l10n
libc6
libc6-dev
libcap-ng0
libcc1-0
libcilkrts5
libcomerr2
libcroco3
libdb5.3
libdebconfclient0
libdevmapper1.02.1
libdpkg-perl
libeatmydata1
libfakeroot
libfdisk1
libffi6
libfile-stripnondeterminism-perl
libgcc-6-dev
libgcc1
libgcrypt20
libgdbm3
libglib2.0-0
libgmp10
libgomp1
libgpg-error0
libicu57
libisl15
libitm1
liblsan0
liblz4-1
liblzma5
libmagic-mgc
libmagic1
libmount1
libmpc3
libmpfr4
libmpx2
libncurses5
libncursesw5
libpam-modules
libpam-modules-bin
libpam-runtime
libpam0g
libpcre3
libperl5.22
libpipeline1
libquadmath0
libselinux1
libsemanage-common
libsemanage1
libsepol1
libsigsegv2
libsmartcols1
libss2
libstdc++-6-dev
libstdc++6
libsystemd0
libtimedate-perl
libtinfo5
libtool
libtsan0
libubsan0
libudev1
libunistring0
libustr-1.0-1
libuuid1
libxml2
linux-libc-dev
locales
login
lsb-base
m4
make
man-db
mawk
mount
multiarch-support
nano
ncurses-base
ncurses-bin
passwd
patch
perl
perl-base
perl-modules-5.22
po-debconf
sed
sensible-utils
startpar
sysv-rc
sysvinit-utils
tar
tzdata
util-linux
xz-utils
zlib1g

Bug#837030: gdk-pixbuf: FTBFS on most architectures due to test failures

[Bas Couwenberg]

Source: gdk-pixbuf
Version: 2.35.4-1
Severity: serious
Justification: makes the package in question unusable or mostly so
Control: affects -1 src:wxwidgets3.0 src:grass src:qgis

Dear Maintainer,

gdk-pixbuf (2.35.4-1) FTBFS on pretty much all architectures due to test
failures:

 ERROR: pixbuf-composite
 ===
 
 **
 
GLib:ERROR:/build/glib2.0-E8y2Xu/glib2.0-2.49.6/./glib/gtestutils.c:3361:g_test_build_filename_va:
 assertion failed (num_path_segments < G_N_ELEMENTS (pathv)): (16 < 16)
 Aborted
 # random seed: R02Sc22c9ad260066d3d905a7b2bba549525
 1..2
 # Start of pixbuf tests
 ok 1 /pixbuf/composite1
 PASS: pixbuf-composite 1 /pixbuf/composite1
 # 
GLib:ERROR:/build/glib2.0-E8y2Xu/glib2.0-2.49.6/./glib/gtestutils.c:3361:g_test_build_filename_va:
 # assertion failed (num_path_segments < G_N_ELEMENTS (pathv)): (16 < 16)
 ERROR: pixbuf-composite - too few tests run (expected 2, got 1)
 ERROR: pixbuf-composite - exited with status 134 (terminated by signal 6?)

This subsequently causes uninstallable build dependencies of its reverse
dependencies.

Kind Regards,

Bas

Bug#836917: transition: openmpi

[Sebastiaan Couwenberg]

On 09/08/2016 12:00 AM, Emilio Pozuelo Monfort wrote:
> On 07/09/16 10:25, Bas Couwenberg wrote:
>> It sadly seems to be the season of uncoordinated transitions, with some
>> maintainers not learning for their past mistakes. Very disappointing.
> 
> It's already started, so let's tag it as such.
> 
> I have urgented proj so that e.g. vtk6 can migrate and doesn't get tangled 
> with
> this transition.

Many thanks for that!

I'm about halfway through the rebuilds of the openmpi rdeps, I should
have the results of that sometime tomorrow.

Kind Regards,

Bas

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

Bug#836442: midori: cannot open local HTML files

[Sergio Durigan Junior]

On Tuesday, September 06 2016, Vincent Lefevre wrote:

> On 2016-09-06 17:07:07 -0400, Sergio Durigan Junior wrote:
>> What Desktop Environment are you using?
>
> I do not use any desktop environment (just fvwm as my window manager).
>
> If I use "xdg-mime query filetype ...", I get text/html. So, this
> does not explain Midori's behavior.

I also get text/html.

> In the strace output, I can see that
>
>   ~/.local/share/mime/application/x-extension-html.xml
>
> is opened. It contains:
>
> 
> http://www.freedesktop.org/standards/shared-mime-info; 
> type="application/x-extension-html">
>   
>   html document
>   
> 
>
> So, this comes from the shared-mime-info package.

This is strange.  I do not have this file, and I have the
shared-mime-info package installed.  I wonder where this file came from
(i.e., which package actually triggered update-mime-database).
Unfortunately you won't be able to use 'dpkg-query -S' on it.  I tried
searching on codesearch.d.n to see if any package installed this file,
but couldn't find anything.

I tried to create this file on my $HOME, but I still can't reproduce the
bug.  Can you please try to temporarily remove the file and see if it
fixes the problem?

> I wonder why type="application/x-extension-html" and not
> type="text/html", but ideally, the real MIME type should be
> obtained by sniffing, not by using the extension. Perhaps it
> is the intent of the generic application/x-extension-html?

Right, I don't know too.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#837003: glib2.0: FTBFS: tests failures

[Simon McVittie]

On Wed, 07 Sep 2016 at 23:56:44 +0200, Lucas Nussbaum wrote:
> > # 
> > GLib:ERROR:/<>/./glib/tests/gdatetime.c:221:test_GDateTime_equal:
> >  assertion failed (g_date_time_get_utc_offset (dt1) / G_USEC_PER_SEC == (-3 
> > * 3600)): (0 == -10800)

This appears to be the only failure here.

Does your test system perhaps not have tzdata installed, despite it being
Priority: required? I know that doesn't technically make it
build-essential - only a dependency from build-essential or Essential: yes
would do that - so if glib2.0 needs it for tests it should build-depend
on it, but in practice I suspect the official buildds all have it, which
would explain why we haven't seen this fail before.

> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2016/09/06/glib2.0_2.49.6-1_unstable.log

The requested URL /~lucas/logs/2016/09/06/glib2.0_2.49.6-1_unstable.log
was not found on this server.

S

Bug#836266: [pkg-gnupg-maint] Bug#836266: dirmngr: Please disable "use-tor" by default.

[Daniel Kahn Gillmor]

Control: reassign 836266 parcimonie
Control: affects 836266 + dirmngr

On Wed 2016-09-07 17:31:17 +0200, Felipe Sateler wrote:
> On Thu, 01 Sep 2016 17:00:19 +0900 Kyuma Ohta  
> wrote:
>> Package: dirmngr
>> Version: 2.1.15-2
>> Severity: important
>>
>> Dear Maintainer,
>> Running gnupg2 with dirmngr, sometimes failed to connect to keyserver.
>> I checked configuration files, automatically add "use-tor" to
>> ~/.gnupg/dirmngr.conf .

dirmngr defaults to having use-tor set to false, and does not
automatically add use-tor to ~/.gnupg/dirmngr.conf

>> So, I stopped dirmngr via gpgconf, and delete this line of dirmngr.conf,
>> and running gnupg2 to access to keyserver, this succeeded.
>>
>> But, after about 15min, re-run gnupg2 to access to keyserver, faied.
>> I checked dirmngr.conf again, added "use-tor" again

I suspect that you have parcimonie installed, since it appears to
automatically ask dirmngr to use tor:

  https://codesearch.debian.net/search?q=use-tor=1

Do you have it installed?  Is it configured and running for you?

>> At some ISPs, tor connection has rejected by default, maybe gnupg2
>> fails to connect to keyserver by default.
>
> Not only this, but dirmngr does not detect the availability of tor,
> and thus fails to work if tor is not installed (or uninstalled after
> the first use).

If dirmngr is configured to use tor, and tor is off or broken or
uninstalled, it should indeed fail to work (rather than contacting the
keyservers without using tor).  that's proper behavior, i think.
(though i agree that better error messages or warnings would make the
failure easier to diagnose and understand, and would be a positive
improvement)

I'm reassigning this bug to parcimonie, because that's where use-tor is
being set automatically.

   --dkg


signature.asc
Description: PGP signature

Bug#837000: kerberos-configs: FTBFS: Undefined subroutine ::read_config called at ./genblob line 9.

[Sam Hartman]

> "Lucas" == Lucas Nussbaum  writes:

Lucas> Hi,

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

Lucas> Relevant part (hopefully):
>> fakeroot debian/rules binary ./genblob >tmp & tmp config-blob
>> Undefined subroutine ::read_config called at ./genblob line
>> 9.  debian/rules:17: recipe for target 'config-blob' failed make:
>> *** [config-blob] Error 2

Lucas> The full build log is available from:
Lucas> 
http://people.debian.org/~lucas/logs/2016/09/06/kerberos-configs_2.3_unstable.log

Lucas> A list of current common problems and possible solutions is
Lucas> available at http://wiki.debian.org/qa.debian.org/FTBFS
Lucas> . You're welcome to contribute!

Lucas> About the archive rebuild: The rebuild was done on EC2 VM
Lucas> instances from Amazon Web Services, using a clean, minimal
Lucas> and up-to-date chroot. Every failed build was retried once to
Lucas> eliminate random failures.

Looks like a . removed from cwd bug in perl.
Kerberos-configs is a bit over-due for some love anyway.
The fix is easy, but I'll go fold in a bunch of other bugs while I get
to it.


--Sam

Bug#837006: gnome-python-desktop: FTBFS: /usr/share/cdbs/1/class/autotools.mk:44: *** no python implementation resolved from binary package "stamp-autotools". Stop.

[Michael Biebl]

Hi Lucas,

thanks for your bug report

Am 07.09.2016 um 23:57 schrieb Lucas Nussbaum:
>> touch debian/stamp-autotools-files
>> /usr/share/cdbs/1/class/autotools.mk:44: *** no python implementation 
>> resolved from binary package "stamp-autotools".  Stop.

That looks like (yet another) cdbs regression and should probably be
re-assigned (along with #837024)

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#836987: RFS: hoichess/0.19.0-2 [QA]

[Eriberto Mota]

Hi,

2016-09-07 19:39 GMT-03:00 Jeremy Bicha :
> On Wed, Sep 7, 2016 at 5:53 PM, Eriberto  wrote:
>> I did an upload for this package some hours ago and I can sponsor this
>> package again. A question: will you really put this package in Collab
>> Maint?
>
> Yes, the packaging is there now. The documentation says that when a
> new repo is created on Alioth, it takes up to 6 hours before the web
> view is live.


Ok.


> https://anonscm.debian.org/git/collab-maint/hoichess.git/
>
> Sorry about the 2nd upload in the same day but this fixes a long-time
> minor annoyance. :)


No problem. Thanks a lot for you work. Uploaded.

Regards,

Eriberto

Bug#837029: gnuchess-book: Consider packaging gnuchess-book source

[Jeremy Bicha]

Source: gnuchess-book
Version: 1.02-2
Severity: wishlist

It appears that if hoichess has access to the gnuchess-book source,
hoichess can build its opening book and Debian bug #401164 can be
closed.

I believe step 1 then is to ship the gnuchess-book source as a
separate binary package (named gnuchess-book-source or something).

Step 2 would then be to figure out how to tell hoichess to use that
file in its build. See

https://anonscm.debian.org/git/collab-maint/hoichess.git/tree/book/Makefile

I don't play chess so I'm not sure how to test whether this works.

Thanks,
Jeremy Bicha

Bug#836940: [buildd-tools-devel] Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[James Clarke]

> On 7 Sep 2016, at 23:01, Markus Koschany  wrote:
> 
> On 07.09.2016 23:24, Mattia Rizzolo wrote:
>> Pbuilder (and therefore cowbuilder) already use --variant=buildd
>> 
>> That afaik is --variant=minbase + build-essential.
>> 
>> I'm not sure why you still get gnupg installed.
>> 
>> Btw what version are you using (of cowbuilder and pbuilder)?
> 
> I'm using the latest packages from sid (cowbuilder 0.80, pbuilder
> 0.226). I'm not sure but I believe exporting
> DEBOOTSTRAPOPTS=--variant=buildd solved the issue for me. GnuPG is no
> longer installed by default. I'm using a slightly modified version of
> Ubuntu's .pbuilderrc which I have once copied from

--variant=buildd is the default; if not, that’s your pbuilderrc (either
/etc/pbuilderrc or ~/.pbuilderrc) at fault.

James

Bug#756479: [Pkg-nagios-devel] Bug#756479: Bug#756479: nagios-nrpe-server: Ignores dont_blame_nrpe=1

[diego.roc...@gmail.com]

I too am experiencing big problems with this change. It blocked all my
debian  8 upgrade.
It doesn't make sense to remove a feature because it can be used the wrong
way

-- 
Diego Roccia
diego.roccia (at) gmail (dot) com

Bug#837017: libvisio: FTBFS: Tests failures

[Rene Engelhard]

tag 837017 + moreinfo
tag 837017 + unreproducible
thanks

Hi,

On Thu, Sep 08, 2016 at 12:16:24AM +0200, Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > make[6]: *** [test-suite.log] Error 1
> > make[6]: Leaving directory '/<>/src/test'
> > Makefile:892: recipe for target 'check-TESTS' failed
> > make[5]: *** [check-TESTS] Error 2
> > make[5]: Leaving directory '/<>/src/test'
> > Makefile:965: recipe for target 'check-am' failed
> > make[4]: *** [check-am] Error 2
> > make[4]: Leaving directory '/<>/src/test'
> > Makefile:394: recipe for target 'check-recursive' failed
> > make[3]: *** [check-recursive] Error 1
> > make[3]: Leaving directory '/<>/src'
> > Makefile:501: recipe for target 'check-recursive' failed
> > make[2]: *** [check-recursive] Error 1
> > make[2]: Leaving directory '/<>'
> > dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
> > debian/rules:14: recipe for target 'override_dh_auto_test' failed

Nope.

> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2016/09/06/libvisio_0.1.5-1_unstable.log

404

And a apt-get -b source libvisio works fine here.

Regards,

Rene

Bug#836987: RFS: hoichess/0.19.0-2 [QA]

[Jeremy Bicha]

On Wed, Sep 7, 2016 at 5:53 PM, Eriberto  wrote:
> I did an upload for this package some hours ago and I can sponsor this
> package again. A question: will you really put this package in Collab
> Maint?

Yes, the packaging is there now. The documentation says that when a
new repo is created on Alioth, it takes up to 6 hours before the web
view is live.

https://anonscm.debian.org/git/collab-maint/hoichess.git/

Sorry about the 2nd upload in the same day but this fixes a long-time
minor annoyance. :)

Thanks,
Jeremy

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

[Boyuan Yang]

2016-09-08 0:52 GMT+08:00 Sean Whitton :
> The issue is that then we then have multiple copies of the thrift files
> in Debian: a copy in each source package that needs them, either for
> regeneration or in debian/missing-sources/.
>
> Suppose there is an Evernote protocol change, or some other bug that
> means the thrift files get updated.  If there is one copy of them in
> Debian, we just update that, and then binNMU all the packages that use
> it, and we're done.

Unfortunately things will not be the case, at least not for Evernote thrift
files.

I had some discussions to the current maintainer of QEverCloud about
the possibility of updating thrift IDL files and regenerate again.
https://github.com/d1vanov/QEverCloud/issues/5

He just told me it is not possible, since the generator needs to be
updated. Update in Evernote thrift files will simply leads to FTBFS
without the update in the generator.

> Otherwise, if there are lots of copies, we have to update each package
> separately.  That's significantly more work, and can't be done by just
> one person, but needs the involvement of the maintainers of all those
> packages.
>
> This is especially relevant if we need to update the thrift files in a
> Debian stable release: updates to packages in a released version of
> Debian have to go through a careful vetting procedure, and this means we
> only have to do that once.  That saves a lot of time (and indeed makes
> it feasible at all).
>
> It's possible I've misunderstood the purpose of the thrift files, though
> -- if there was an Evernote API change, they would have to change and
> the corresponding language-specific generators re-run, right?

In this specific case, we also need to notice the slow evolvement of
Evernote Cloud API (>= 3 years, longer than Debian stable release cycle.
Take a look at Evernote official SDK)
and the backward compatibility of the API. Not updating API will not cause
problems, and it is the author of program (i.e., nixnote2 author) who has
the responsibility to update the level of API itself uses. Even if the Evernote
API is updated according to the new thrift files by packagers, the added methods
will not be utilized until the program author decide to switch to the
new API, and
the changed/removed methods may lead to FTBFS.

>> Is there really any previous example in Debian, that one package
>> *should* and *do* Build-Depend on another *binary* package that only
>> contains some description files or source codes?
>
> I'm not sure about a package that only contains source code alone, but I
> can give you an example of one that contains source code plus some other
> stuff: dh-elpa.  If you look in the emacsen-common folder of its source
> package, you'll find some scripts.  Those get copied into every elpa-*
> binary package (with the package name substituted in).  And dh-elpa is
> added to the elpa-* package's Built-Using field.
>
> Before dh-elpa, there was a copy of those emacsen-common scripts in
> every single Emacs lisp addon package (and in package that have not yet
> been converted, it's still there, e.g. s-el).  That meant that fixing
> bugs in those scripts or improving/reworking the Emacs Lisp addon
> packaging policy[1] means updating every single Emacs Lisp addon source
> package, and re-uploading.
>
> Thanks to dh-elpa we can update the scripts in all elpa-* packages just
> by changing dh-elpa, and rebuilding the elpa-* packages.[2]

Unfortunately Evernote thrift files are neither lisp nor shared libraries.
I understand the advantage that common files get updated separately and
a rebuild solves the rest of the problem, but this is not the current case.

>> I checked ebib and find that I know nothing about emacs lisp and its 
>> debhelper.
>> Where did it remove any file?
>
> Take a look at the two overrides in d/rules.  You shouldn't need to know
> anything about Emacs lisp to understand those.

Are we talking about the same package? :p

I ran `apt-get source ebib' and got ebib v4.5.2. The debian/rules is
nothing more
than one line of `dh $@ --parallel --with elpa'.


Sincerely,
Boyuan Yang

Bug#835489: Fails to start

[Dmitry Eremin-Solenikov]

Package: pyqso
Followup-For: Bug #835489

Please consider the attached patch that fixed all the issues of PyQSO vs
Python3. I have uploaded the corresponding package to
mentors.debian.net (https://mentors.debian.net/package/pyqso). Thanks in 
advance.

-- 
With best wishes
Dmitry

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

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

Versions of packages pyqso depends on:
ii  gir1.2-gtk-3.0   3.21.5-3
ii  libjs-jquery 1.12.4-1
ii  libjs-underscore 1.8.3~dfsg-1
ii  python-libhamlib23.0.1-1
ii  python3-gi-cairo 3.20.1-1
ii  python3-matplotlib   1.5.2~rc2-1
ii  python3-mpltoolkits.basemap  1.0.7+dfsg-4
ii  python3-numpy1:1.11.1~rc1-1
pn  python3:any  

pyqso recommends no packages.

pyqso suggests no packages.

-- no debconf information
diff -Napur pyqso-0.3-old/debian/changelog pyqso-0.3/debian/changelog
--- pyqso-0.3-old/debian/changelog	2016-07-08 04:55:53.0 +0300
+++ pyqso-0.3/debian/changelog	2016-09-08 01:01:19.026455214 +0300
@@ -1,3 +1,14 @@
+pyqso (0.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild with Python3 (Closes: #835489).
+  * Change packages in dependencies to rerefence Python3 packages.
+  * Move python(3)-libhamlib2 to Recomends, as the Python3 version of package
+is not yet available in Debian.
+  * Bump standards version to 3.9.8 (No changes needed).
+
+ -- Dmitry Eremin-Solenikov   Thu, 08 Sep 2016 01:00:46 +0300
+
 pyqso (0.3-1) unstable; urgency=medium
 
   * Imported Upstream version 0.3.
diff -Napur pyqso-0.3-old/debian/control pyqso-0.3/debian/control
--- pyqso-0.3-old/debian/control	2016-07-08 04:51:02.0 +0300
+++ pyqso-0.3/debian/control	2016-09-08 01:01:46.095566806 +0300
@@ -5,10 +5,10 @@ Section: hamradio
 Priority: optional
 Build-Depends: debhelper (>= 9),
dh-python,
-   python-all,
+   python3-all,
python-setuptools,
python-sphinx
-Standards-Version: 3.9.6
+Standards-Version: 3.9.8
 Vcs-Browser: http://anonscm.debian.org/cgit/pkg-hamradio/pyqso.git
 Vcs-Git: http://anonscm.debian.org/git/pkg-hamradio/pyqso.git
 Homepage: http://christianjacobs.uk/pyqso
@@ -16,15 +16,15 @@ Homepage: http://christianjacobs.uk/pyqs
 Package: pyqso
 Architecture: all
 Depends: ${misc:Depends},
- ${python:Depends},
- python-libhamlib2,
+ ${python3:Depends},
  gir1.2-gtk-3.0,
- python-gi-cairo,
- python-mpltoolkits.basemap,
- python-numpy,
- python-matplotlib,
+ python3-gi-cairo,
+ python3-mpltoolkits.basemap,
+ python3-numpy,
+ python3-matplotlib,
  libjs-jquery,
  libjs-underscore
+Recommends: python3-libhamlib2,
 Description: logging tool for amateur radio operators
  PyQSO is a logging tool for amateur radio operators. It provides a simple
  graphical interface through which users can manage information about the
diff -Napur pyqso-0.3-old/debian/rules pyqso-0.3/debian/rules
--- pyqso-0.3-old/debian/rules	2016-07-08 04:51:02.0 +0300
+++ pyqso-0.3/debian/rules	2016-09-08 00:38:38.589181137 +0300
@@ -2,7 +2,7 @@
 export PYBUILD_NAME=pyqso
 
 %:
-	dh $@ --with python2 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_build:
 	PYTHONPATH=. http_proxy='localhost' sphinx-build -N -bhtml docs/source/ build/html  # HTML generator

Bug#837027: csh: FTBFS: proc.c:84:16: error: storage size of 'w' isn't known

[Lucas Nussbaum]

Source: csh
Version: 20110502-2.1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> cc -g -O2 -Wno-error -I/<> -I. -DBUILTIN -DFILEC -DNLS 
> -DSHORT_STRINGS -D_GNU_SOURCE  -Werror   -c proc.c
> proc.c: In function 'pchild':
> proc.c:84:16: error: storage size of 'w' isn't known
>  union wait w;
> ^
> *** Error code 1
> 
> Stop.
> bmake[2]: stopped in /<>
> dh_auto_build: bmake returned exit code 1
> debian/rules:10: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 1

The full build log is available from:
   http://people.debian.org/~lucas/logs/2016/09/06/csh_20110502-2.1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#834744: xmlgraphics-commons: FTBFS (missing build-depends on gnupg)

[Lucas Nussbaum]

severity 834744 serious
thanks

On 07/09/16 at 14:17 +0100, Santiago Vila wrote:
> I suggest to raise the severity now

Yes.

Lucas

Bug#836940: [buildd-tools-devel] Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[Thorsten Glaser]

Santiago Vila dixit:

>For the record: This is a false dichotomy, because xmlgraphics-commons
>didn't fail in the official buildds. it didn't fail in a

You miss a word there: “yet”

An undeclared build dependency on a non-Essential/Build-Essential
package is an RC bug in the package. That includes when needed
packages were previously provided by other build dependencies (by
virtue of being run-time dependencies of such) but no longer are.

bye,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”

Bug#835420: bridge-utils: enabling rp_filter causes network to hang

[Santiago Garcia Mantinan]

Hi!

This is starting to be a question on how to to things and not a bugreport. I
still cannot understand what you really are trying to do, for interfaces
with a name you want you should look at iproute's doc, the ip command can
give you aliases with any name you want, for info on how to do this on
/etc/network/interfaces the doc of ifupdown starting with man interfaces
should guide you.

If you still feel you want a bridge and that there is an issue with that on
Debian, like you seem to suggest here:

> If the original eth0 is brought up first, and then the bridge (say, eth1)
> (or br1) is brought up second there are no issues really to begin with.
> 
> However if the eth0 is then brought down, and we test the connection, the
> bridge still functions, but eth0 doesn't work anymore. Then, if I bring down
> the bridge and bring it back up again, eth0 functions again.

I need to know what is broken, like you have just explained here, but also
the files that may have implications with the bridge-utils behaviour here,
like the full /etc/network/interfaces and also /etc/default/bridge-utils

And if you send me the status of the interfaces before and after doing those
commands and what commands you are really using then it would be great.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#837028: gauche-gtk: FTBFS: pango-font.c:249:44: error: 'desc' undeclared (first use in this function)

[Lucas Nussbaum]

Source: gauche-gtk
Version: 0.6~pre1+git20121223-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> gcc -DHAVE_CONFIG_H -g -O2 
> -fdebug-prefix-map=/<>/gauche-gtk-0.6~pre1+git20121223=. 
> -fstack-protector-strong -Wformat -Werror=format-security -I. `gauche-config 
> -I` `gauche-config --so-cflags` `pkg-config --cflags gtk+-2.0` -Wdate-time 
> -D_FORTIFY_SOURCE=2  -c -o pango-font.o pango-font.c
> pango-font.c: In function 'pango_font_pango_font_description_to_string':
> pango-font.c:249:44: error: 'desc' undeclared (first use in this function)
>  char *s = pango_font_description_to_string(desc);
> ^~~~
> pango-font.c:249:44: note: each undeclared identifier is reported only once 
> for each function it appears in
> pango-font.c: In function 'pango_font_pango_font_description_to_filename':
> pango-font.c:267:46: error: 'desc' undeclared (first use in this function)
>  char *s = pango_font_description_to_filename(desc);
>   ^~~~
> : recipe for target 'pango-font.o' failed
> make[2]: *** [pango-font.o] Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/gauche-gtk_0.6~pre1+git20121223-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837026: tcsh: FTBFS: sh.proc.c:155:16: error: storage size of 'w' isn't known

[Lucas Nussbaum]

Source: tcsh
Version: 6.18.01-5
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> gcc -c -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -D_FILE_OFFSET_BITS=64 -I. -I. 
> -D_PATH_TCSHELL='"/usr/bin/tcsh"'  -Wdate-time -D_FORTIFY_SOURCE=2  sh.proc.c
> In file included from /usr/include/signal.h:28:0,
>  from sh.h:39,
>  from sh.proc.c:33:
> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and 
> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
>  # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
>^~~
> sh.proc.c: In function 'pchild':
> sh.proc.c:155:16: error: storage size of 'w' isn't known
>  union wait w;
> ^
> Makefile:465: recipe for target 'sh.proc.o' failed
> make[2]: *** [sh.proc.o] Error 1

The full build log is available from:
   http://people.debian.org/~lucas/logs/2016/09/06/tcsh_6.18.01-5_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837021: openjfx: FTBFS: PosixPlatform.cpp:235:10: error: 'wait' was not declared in this scope

[Lucas Nussbaum]

Source: openjfx
Version: 8u102-b14-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> g++ -Xlinker -s -static-libstdc++ -Wl,-O1 -shared -o libDumpRenderTreeJava.so 
> Release/obj/GCController.o Release/obj/TestRunner.o Release/obj/WorkQueue.o 
> Release/obj/DumpRenderTree.o Release/obj/GCControllerJava.o 
> Release/obj/JavaEnv.o Release/obj/TestRunnerJava.o 
> Release/obj/WorkQueueItemJava.o Release/obj/EventSender.o  
> -L../../Release/lib -lpthread -ljfxwebkit  
> mv -f libDumpRenderTreeJava.so ../../Release/lib/ 
> make[3]: Leaving directory 
> '/<>/modules/web/build/linux/Tools/DumpRenderTree'
> make[2]: Leaving directory '/<>/modules/web/build/linux/Release'
> 
> 
>  WebKit is now built (1h:03m:38s). 
>  To run FXLauncher with this newly-built code, use the
>  "Tools/Scripts/run-launcher" script.
> 
> :web:compileNativeLinux (Thread[main,5,main]) completed. Took 1 hrs 3 mins 
> 38.269 secs.
> :web:compileGeneratedLinux (Thread[main,5,main]) started.
> :web:compileGeneratedLinux
> Executing task ':web:compileGeneratedLinux' (up-to-date check took 0.075 
> secs) due to:
>   No history is available.
> All input files are considered out-of-date for incremental task 
> ':web:compileGeneratedLinux'.
> Compiling with Java command line compiler 
> '/usr/lib/jvm/java-8-openjdk-amd64/bin/javac'.
> Starting process 'command '/usr/lib/jvm/java-8-openjdk-amd64/bin/javac''. 
> Working directory: /<>/modules/web Command: 
> /usr/lib/jvm/java-8-openjdk-amd64/bin/javac 
> @/<>/modules/web/build/tmp/compileGeneratedLinux/java-compiler-args.txt
> Successfully started process 'command 
> '/usr/lib/jvm/java-8-openjdk-amd64/bin/javac''
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> :web:compileGeneratedLinux (Thread[main,5,main]) completed. Took 3.056 secs.
> :web:compileGenerated (Thread[main,5,main]) started.
> :web:compileGenerated
> Skipping task ':web:compileGenerated' as it has no actions.
> :web:compileGenerated (Thread[main,5,main]) completed. Took 0.0 secs.
> :web:drtJar (Thread[main,5,main]) started.
> :web:drtJar
> Executing task ':web:drtJar' (up-to-date check took 0.007 secs) due to:
>   No history is available.
> :web:drtJar (Thread[main,5,main]) completed. Took 0.028 secs.
> :web:jar (Thread[main,5,main]) started.
> :web:jar
> Executing task ':web:jar' (up-to-date check took 0.02 secs) due to:
>   No history is available.
> :web:jar (Thread[main,5,main]) completed. Took 0.166 secs.
> :builders:compileJava (Thread[main,5,main]) started.
> :builders:compileJava
> Executing task ':builders:compileJava' (up-to-date check took 0.046 secs) due 
> to:
>   No history is available.
> All input files are considered out-of-date for incremental task 
> ':builders:compileJava'.
> Compiling with Java command line compiler 
> '/usr/lib/jvm/java-8-openjdk-amd64/bin/javac'.
> Starting process 'command '/usr/lib/jvm/java-8-openjdk-amd64/bin/javac''. 
> Working directory: /<>/modules/builders Command: 
> /usr/lib/jvm/java-8-openjdk-amd64/bin/javac 
> @/<>/modules/builders/build/tmp/compileJava/java-compiler-args.txt
> Successfully started process 'command 
> '/usr/lib/jvm/java-8-openjdk-amd64/bin/javac''
> Note: 
> /<>/modules/builders/src/main/java/javafx/scene/web/WebViewBuilder.java
>  uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> :builders:compileJava (Thread[main,5,main]) completed. Took 3.794 secs.
> :builders:processResources (Thread[main,5,main]) started.
> :builders:processResources
> file or directory '/<>/modules/builders/src/main/resources', not 
> found
> Skipping task ':builders:processResources' as it has no source files.
> :builders:processResources UP-TO-DATE
> :builders:processResources (Thread[main,5,main]) completed. Took 0.001 secs.
> :builders:classes (Thread[main,5,main]) started.
> :builders:classes
> Skipping task ':builders:classes' as it has no actions.
> :builders:classes (Thread[main,5,main]) completed. Took 0.0 secs.
> :builders:jar (Thread[main,5,main]) started.
> :builders:jar
> Executing task ':builders:jar' (up-to-date check took 0.003 secs) due to:
>   No history is available.
> :builders:jar (Thread[main,5,main]) completed. Took 0.053 secs.
> :builders:assemble (Thread[main,5,main]) started.
> :builders:assemble
> Skipping task ':builders:assemble' as it has no actions.
> :builders:assemble (Thread[main,5,main]) completed. Took 0.0 secs.
> :controls:assemble (Thread[main,5,main]) started.
> :controls:assemble
> Skipping task 

Bug#837024: gamin: FTBFS: /usr/share/cdbs/1/class/autotools.mk:44: *** no python implementation resolved from binary package "stamp-autotools". Stop.

[Lucas Nussbaum]

Source: gamin
Version: 0.1.10-5
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>  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
> CDBS WARNING:  copyright-check disabled - touch debian/copyright_hints to 
> enable.
> test -x debian/rules
> mkdir -p "debian/build"
> CDBS WARNING:DEB_DH_BUILDDEB_ARGS is deprecated since 0.4.85
> 
> Scanning upstream source for new/changed copyright notices...
> 
> set -e; LC_ALL=C.UTF-8 /usr/bin/licensecheck --check '.*' --recursive 
> --copyright --deb-fmt --ignore 
> '^(debian/(changelog|copyright(|_hints|_newhints)))$' --lines 0 * | 
> /usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints
> /bin/sh: 1: /usr/bin/licensecheck: not found
> 0 combinations of copyright and licensing found.
> diff: debian/copyright_hints: No such file or directory
> No new copyright notices found - assuming no news is good news...
> touch debian/stamp-copyright-check
> touch debian/stamp-upstream-cruft
> set -e;   mv ./config.guess ./config.guess.cdbs-orig; cp --remove-destination 
> /usr/share/misc/config.guess ./config.guess;
> set -e;   mv ./config.sub ./config.sub.cdbs-orig; cp --remove-destination 
> /usr/share/misc/config.sub ./config.sub;
> dh_autoreconf 
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> configure.in:32: warning: AC_COMPILE_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_RUN_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_COMPILE_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_RUN_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.in,
> libtoolize: and rerunning libtoolize and aclocal.
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> aclocal: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> configure.in:32: warning: AC_COMPILE_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_RUN_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_COMPILE_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_RUN_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_COMPILE_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_RUN_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> automake: warning: autoconf input should be named 'configure.ac', not 
> 'configure.in'
> configure.in:32: warning: AC_COMPILE_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:32: warning: AC_RUN_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:368: AC_USE_SYSTEM_EXTENSIONS is expanded 
> from...
> configure.in:32: the top level
> configure.in:28: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms 
> are deprecated.  For more info, see:
> configure.in:28: 
> http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
> configure.in:30: installing './compile'
> configure.in:28: installing './missing'
> automake: warning: autoconf input should be named 

Bug#837025: pyasn1: FTBFS: debian/rules:16: *** target file 'debian/python-module-stampdir/pypy-pyasn1' has both : and :: entries. Stop.

[Lucas Nussbaum]

Source: pyasn1
Version: 0.1.9-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>  fakeroot debian/rules clean
> py3versions: no X-Python3-Version in control file, using supported versions
> debian/rules:16: *** target file 'debian/python-module-stampdir/pypy-pyasn1' 
> has both : and :: entries.  Stop.
> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
> 
> Build finished at 2016-09-06T23:08:12Z

The full build log is available from:
   http://people.debian.org/~lucas/logs/2016/09/06/pyasn1_0.1.9-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837022: wagon2: FTBFS: dh_auto_test failed

[Lucas Nussbaum]

Source: wagon2
Version: 2.10-4
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> mkdir -p /<>/wagon-providers/wagon-scm/target/test-classes/
> svnadmin create 
> /<>/wagon-providers/wagon-scm/target/test-classes/test-repo-svn
> dh_auto_build
>   /usr/lib/jvm/default-java/bin/java -noverify -cp 
> /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
>  -Dmaven.home=/usr/share/maven 
> -Dmaven.multiModuleProjectDirectory=/<> 
> -Dclassworlds.conf=/etc/maven/m2-debian.conf 
> -Dproperties.file.manual=/<>/debian/maven.properties 
> org.codehaus.plexus.classworlds.launcher.Launcher 
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
> -Dmaven.repo.local=/<>/debian/maven-repo package -DskipTests 
> -Dnotimestamp=true -Dlocale=en_US
> [INFO] Scanning for projects...
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-provider-api:jar:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-file:jar:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-ftp:jar:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-http:jar:2.10
> [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but 
> found duplicate declaration of plugin 
> org.apache.maven.plugins:maven-surefire-plugin @ line 143, column 12
> [WARNING] 'build.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-surefire-plugin is missing. @ line 143, column 
> 12
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-http-shared:jar:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-http-lightweight:jar:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-surefire-plugin is missing. @ line 59, column 
> 12
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-providers:pom:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-provider-test:jar:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-tck-http:jar:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon-tcks:pom:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> org.codehaus.plexus:plexus-component-metadata is missing. @ 
> org.apache.maven.wagon:wagon:2.10, /<>/pom.xml, line 378, column 
> 12
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.wagon:wagon:pom:2.10
> [WARNING] 'build.plugins.plugin.version' for 
> 

Bug#837023: gridengine: FTBFS: ../sh.proc.c:153:16: error: storage size of ‘w’ isn’t known

[Lucas Nussbaum]

Source: gridengine
Version: 8.1.9+dfsg-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> cc -c -O2 -Wstrict-prototypes -DLINUX -DLINUXAMD64 -DLINUXAMD64 -D_GNU_SOURCE 
> -DGETHOSTBYNAME_R6 -DGETHOSTBYADDR_R8 -DTARGET_64BIT -Wdate-time 
> -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>/gridengine-8.1.9+dfsg=. 
> -fstack-protector-strong -Wformat -Werror=format-security -DSGE_PQS_API 
> -DSPOOLING_dynamic -DSECURE -DHAVE_HWLOC=1 -DCOMPILE_DC 
> -D__SGE_COMPILE_WITH_GETTEXT__ -D__SGE_NO_USERMAPPING__ -U_GNU_SOURCE 
> -Wno-error -DPROG_NAME='"qtcsh"' -DLINUXAMD64 -I. -I.. 
> -D_PATH_TCSHELL='"/usr/local/bin/tcsh"'  -Wdate-time -D_FORTIFY_SOURCE=2  
> -I../../../libs/gdi -I../../../libs/gdi ../sh.proc.c
> In file included from /usr/include/signal.h:28:0,
>  from ../sh.h:39,
>  from ../sh.proc.c:33:
> /usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and 
> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
>  # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
>^~~
> ../sh.proc.c: In function ‘pchild’:
> ../sh.proc.c:153:16: error: storage size of ‘w’ isn’t known
>  union wait w;
> ^
> Makefile:381: recipe for target 'sh.proc.o' failed
> make[2]: *** [sh.proc.o] Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/gridengine_8.1.9+dfsg-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837018: gupnp-igd: FTBFS: /usr/share/cdbs/1/class/autotools.mk:44: *** no python implementation resolved from binary package "stamp-autotools". Stop.

[Lucas Nussbaum]

Source: gupnp-igd
Version: 0.2.4-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>  debian/rules build
> CDBS WARNING:  copyright-check disabled - touch debian/copyright_hints to 
> enable.
> test -x debian/rules
> mkdir -p "debian/build"
> 
> Scanning upstream source for new/changed copyright notices...
> 
> set -e; LC_ALL=C.UTF-8 /usr/bin/licensecheck --check '.*' --recursive 
> --copyright --deb-fmt --ignore 
> '^(debian/(changelog|copyright(|_hints|_newhints)))$' --lines 0 * | 
> /usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints
> /bin/sh: 1: /usr/bin/licensecheck: not found
> 0 combinations of copyright and licensing found.
> diff: debian/copyright_hints: No such file or directory
> No new copyright notices found - assuming no news is good news...
> touch debian/stamp-copyright-check
> touch debian/stamp-upstream-cruft
> set -e;   mv ./config.guess ./config.guess.cdbs-orig; cp --remove-destination 
> /usr/share/misc/config.guess ./config.guess;
> set -e;   mv ./config.sub ./config.sub.cdbs-orig; cp --remove-destination 
> /usr/share/misc/config.sub ./config.sub;
> dh_autoreconf 
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> libtoolize: copying file 'm4/libtool.m4'
> libtoolize: copying file 'm4/ltoptions.m4'
> libtoolize: copying file 'm4/ltsugar.m4'
> libtoolize: copying file 'm4/ltversion.m4'
> libtoolize: copying file 'm4/lt~obsolete.m4'
> configure.ac:8: installing './compile'
> configure.ac:3: installing './missing'
> libgupnp-igd/Makefile.am: installing './depcomp'
> touch debian/stamp-autotools-files
> /usr/share/cdbs/1/class/autotools.mk:44: *** no python implementation 
> resolved from binary package "stamp-autotools".  Stop.
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> Build finished at 2016-09-06T22:51:00Z

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/gupnp-igd_0.2.4-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837020: liblightify: FTBFS: doxygen-include.am:47: error: DX_COND_doc does not appear in AM_CONDITIONAL

[Lucas Nussbaum]

Source: liblightify
Version: 0~git20160607-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>  debian/rules build
> dh build  --with autoreconf
>dh_testdir
>dh_update_autotools_config
>dh_autoreconf
> aclocal: warning: couldn't open directory 'm4': No such file or directory
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
> libtoolize: copying file 'build-aux/ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> libtoolize: copying file 'm4/libtool.m4'
> libtoolize: copying file 'm4/ltoptions.m4'
> libtoolize: copying file 'm4/ltsugar.m4'
> libtoolize: copying file 'm4/ltversion.m4'
> libtoolize: copying file 'm4/lt~obsolete.m4'
> configure.ac:24: installing 'build-aux/compile'
> configure.ac:86: installing 'build-aux/config.guess'
> configure.ac:86: installing 'build-aux/config.sub'
> configure.ac:11: installing 'build-aux/install-sh'
> configure.ac:11: installing 'build-aux/missing'
> configure.ac:9: installing 'build-aux/tap-driver.sh'
> doxygen-include.am:47: error: DX_COND_doc does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:53: error: DX_COND_html does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:63: error: DX_COND_chm does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:67: error: DX_COND_chi does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:79: error: DX_COND_man does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:89: error: DX_COND_rtf does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:99: error: DX_COND_xml does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:109: error: DX_COND_ps does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:138: error: DX_COND_pdf does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> doxygen-include.am:167: error: DX_COND_latex does not appear in AM_CONDITIONAL
> Makefile.am:1:   'doxygen-include.am' included from here
> Makefile.am:4: error: DX_COND_doc does not appear in AM_CONDITIONAL
> Makefile.am:18: error: DX_COND_doc does not appear in AM_CONDITIONAL
> Makefile.am: installing 'build-aux/depcomp'
> parallel-tests: installing 'build-aux/test-driver'
> autoreconf: automake failed with exit status: 1
> dh_autoreconf: autoreconf -f -i returned exit code 1
> debian/rules:4: recipe for target 'build' failed
> make: *** [build] Error 2

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/liblightify_0~git20160607-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837019: zvbi: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[Lucas Nussbaum]

Source: zvbi
Version: 0.2.35-11
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> make[4]: Entering directory '/<>/test'
> PASS: ctest
> PASS: cpptest
> PASS: ctest-c89
> PASS: ctest-gnu89
> PASS: ctest-c94
> PASS: ctest-c99
> PASS: ctest-gnu99
> PASS: cpptest-cxx98
> PASS: cpptest-gnuxx98
> PASS: exoptest
> PASS: test-dvb_demux
> PASS: test-dvb_mux
> PASS: test-hamm
> PASS: test-packet-830
> ../test-driver: line 107: 20549 Aborted "$@" > $log_file 2>&1
> FAIL: test-pdc
> PASS: test-raw_decoder
> PASS: test-unicode
> PASS: test-vps
> ==
>zvbi 0.2.35: test/test-suite.log
> ==
> 
> # TOTAL: 18
> # PASS:  17
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> .. contents:: :depth: 2
> 
> FAIL: test-pdc
> ==
> 
> test-pdc: test-pdc.cc:1078: void test_pil_to_time(): Assertion `ztime 
> ("20010215T19") == vbi_pil_to_time (VBI_PIL (2, 15, 20, 0), t1, 
> "Europe/Paris")' failed.
> FAIL test-pdc (exit status: 134)
> 
> 
> Testsuite summary for zvbi 0.2.35
> 
> # TOTAL: 18
> # PASS:  17
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See test/test-suite.log
> 
> Makefile:1466: recipe for target 'test-suite.log' failed
> make[4]: *** [test-suite.log] Error 1
> make[4]: Leaving directory '/<>/test'
> Makefile:1572: recipe for target 'check-TESTS' failed
> make[3]: *** [check-TESTS] Error 2
> make[3]: Leaving directory '/<>/test'
> Makefile:1764: recipe for target 'check-am' failed
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory '/<>/test'
> Makefile:510: recipe for target 'check-recursive' failed
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory '/<>'
> dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

The full build log is available from:
   http://people.debian.org/~lucas/logs/2016/09/06/zvbi_0.2.35-11_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837013: notmuch: FTBFS: Tests failures

[Lucas Nussbaum]

Source: notmuch
Version: 0.22.1-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> gpg: no valid OpenPGP data found.
> Added 2 new messages to the database.
>  missing prerequisites: database-v1.tar.xz - fetch with 'make 
> download-test-databases'
>  SKIP   all tests in T530-upgrade
>  BROKEN No ghosts should remain after deletion of second message
>   --- T590-thread-breakage.22.expected2016-09-06 22:45:08.15600 
> +
>   +++ T590-thread-breakage.22.output  2016-09-06 22:45:08.15600 
> +
>   @@ -1 +1 @@
>   -0
>   +1
> 
> Notmuch test suite complete.
> 772/778 tests passed.
> 1 broken test failed as expected.
> 5 tests failed.
> test/Makefile.local:64: recipe for target 'test' failed

The full build log is available from:
   http://people.debian.org/~lucas/logs/2016/09/06/notmuch_0.22.1-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837012: tachyon: FTBFS: ld: tachyon_ogl-glwin.o: undefined reference to symbol 'XNextEvent'

[Lucas Nussbaum]

Source: tachyon
Version: 0.99~b6+dsx-5
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> /bin/bash ../libtool  --tag=CC   --mode=link gcc -Wno-unused-result 
> -I/usr/include/libdrm -I/usr/include/libdrm -g -O3 
> -fdebug-prefix-map=/<>/tachyon-0.99~b6+dsx=. -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT 
> -ffast-math -fomit-frame-pointer   -o tachyon-ogl tachyon_ogl-main.o 
> tachyon_ogl-getargs.o tachyon_ogl-parse.o tachyon_ogl-nffparse.o 
> tachyon_ogl-mgfparse.o tachyon_ogl-ac3dparse.o tachyon_ogl-glwin.o 
> tachyon_ogl-spaceball.o tachyon_ogl-trackball.o ../src/libtachyon.la -lm -lGL 
>  -lGL 
> libtool: link: gcc -Wno-unused-result -I/usr/include/libdrm 
> -I/usr/include/libdrm -g -O3 
> "-fdebug-prefix-map=/<>/tachyon-0.99~b6+dsx=." -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT 
> -ffast-math -fomit-frame-pointer -o .libs/tachyon-ogl tachyon_ogl-main.o 
> tachyon_ogl-getargs.o tachyon_ogl-parse.o tachyon_ogl-nffparse.o 
> tachyon_ogl-mgfparse.o tachyon_ogl-ac3dparse.o tachyon_ogl-glwin.o 
> tachyon_ogl-spaceball.o tachyon_ogl-trackball.o  ../src/.libs/libtachyon.so 
> -lm -lGL
> /usr/bin/ld: tachyon_ogl-glwin.o: undefined reference to symbol 'XNextEvent'
> //usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing 
> from command line
> collect2: error: ld returned 1 exit status

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/tachyon_0.99~b6+dsx-5_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837015: linux-tools: FTBFS: util/event.c:448:2: error: 'readdir_r' is deprecated [-Werror=deprecated-declarations]

[Lucas Nussbaum]

Source: linux-tools
Version: 4.4.6-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>   gcc 
> -Wp,-MD,/<>/debian/build/tools/perf/out/util/.event.o.d,-MT,/<>/debian/build/tools/perf/out/util/event.o
>  -g -O2 -fdebug-prefix-map=/<>/debian/build/tools/perf=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time 
> -D_FORTIFY_SOURCE=2 -I/<>/tools/perf 
> -I/<>/debian/build/tools/perf -isystem 
> /<>/debian/build/include -Wno-error -DHAVE_ARCH_X86_64_SUPPORT 
> -DHAVE_PERF_REGS_SUPPORT -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET -Werror -O6 
> -fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall -Wextra -std=gnu99 
> -fstack-protector-all -D_FORTIFY_SOURCE=2 
> -I/<>/tools/perf/util/include 
> -I/<>/tools/perf/arch/x86/include 
> -I/<>/tools/include/ -I/<>/arch/x86/include/uapi 
> -I/<>/arch/x86/include -I/<>/include/uapi 
> -I/<>/include 
> -I/<>/debian/build/tools/perf/out//util 
> -I/<>/debian/build/tools/perf/out/ 
> -I/<>/tools/perf/util -I/<>/tools/perf 
> -I/<>/tools/lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_GNU_SOURCE -DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT 
> -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_LIBELF_SUPPORT 
> -DHAVE_LIBELF_MMAP_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_DWARF_SUPPORT 
>  -DHAVE_LIBBPF_SUPPORT -DHAVE_DWARF_UNWIND_SUPPORT -DNO_LIBUNWIND_DEBUG_FRAME 
> -DHAVE_LIBUNWIND_SUPPORT  -DHAVE_LIBAUDIT_SUPPORT -I/usr/include/slang 
> -DHAVE_SLANG_SUPPORT -DHAVE_TIMERFD_SUPPORT -DHAVE_CPLUS_DEMANGLE_SUPPORT 
> -DHAVE_ZLIB_SUPPORT -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT 
> -DHAVE_KVM_STAT_SUPPORT -DHAVE_PERF_READ_VDSO32 -DHAVE_PERF_READ_VDSOX32 
> -DHAVE_AUXTRACE_SUPPORT -I/<>/debian/build/tools/perf/out/ 
> -D"BUILD_STR(s)=#s"   -c -o 
> /<>/debian/build/tools/perf/out/util/event.o util/event.c
> util/event.c: In function '__event__synthesize_thread':
> util/event.c:448:2: error: 'readdir_r' is deprecated 
> [-Werror=deprecated-declarations]
>   while (!readdir_r(tasks, , ) && next) {
>   ^
> In file included from /usr/include/features.h:364:0,
>  from /usr/include/stdint.h:25,
>  from /usr/lib/gcc/x86_64-linux-gnu/6/include/stdint.h:9,
>  from /<>/tools/include/linux/types.h:6,
>  from util/event.c:1:
> /usr/include/dirent.h:189:12: note: declared here
>  extern int __REDIRECT (readdir_r,
> ^
> util/event.c: In function 'perf_event__synthesize_threads':
> util/event.c:586:2: error: 'readdir_r' is deprecated 
> [-Werror=deprecated-declarations]
>   while (!readdir_r(proc, , ) && next) {
>   ^
> In file included from /usr/include/features.h:364:0,
>  from /usr/include/stdint.h:25,
>  from /usr/lib/gcc/x86_64-linux-gnu/6/include/stdint.h:9,
>  from /<>/tools/include/linux/types.h:6,
>  from util/event.c:1:
> /usr/include/dirent.h:189:12: note: declared here
>  extern int __REDIRECT (readdir_r,
> ^
> cc1: all warnings being treated as errors
> mv: cannot stat 
> '/<>/debian/build/tools/perf/out/util/.event.o.tmp': No such 
> file or directory
> /<>/tools/build/Makefile.build:77: recipe for target 
> '/<>/debian/build/tools/perf/out/util/event.o' failed
> make[8]: *** [/<>/debian/build/tools/perf/out/util/event.o] 
> Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/linux-tools_4.4.6-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837017: libvisio: FTBFS: Tests failures

[Lucas Nussbaum]

Source: libvisio
Version: 0.1.5-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> make[6]: *** [test-suite.log] Error 1
> make[6]: Leaving directory '/<>/src/test'
> Makefile:892: recipe for target 'check-TESTS' failed
> make[5]: *** [check-TESTS] Error 2
> make[5]: Leaving directory '/<>/src/test'
> Makefile:965: recipe for target 'check-am' failed
> make[4]: *** [check-am] Error 2
> make[4]: Leaving directory '/<>/src/test'
> Makefile:394: recipe for target 'check-recursive' failed
> make[3]: *** [check-recursive] Error 1
> make[3]: Leaving directory '/<>/src'
> Makefile:501: recipe for target 'check-recursive' failed
> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory '/<>'
> dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
> debian/rules:14: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   http://people.debian.org/~lucas/logs/2016/09/06/libvisio_0.1.5-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837016: singular: FTBFS: aminclude.am:35: error: DX_COND_doc does not appear in AM_CONDITIONAL

[Lucas Nussbaum]

Source: singular
Version: 4.0.3-p1+ds-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>  debian/rules build
> dh build --with autoreconf --parallel
>dh_testdir
>dh_update_autotools_config
>dh_autoreconf
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '../build-aux'.
> libtoolize: copying file '../build-aux/ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, '../m4'.
> libtoolize: copying file '../m4/libtool.m4'
> libtoolize: copying file '../m4/ltoptions.m4'
> libtoolize: copying file '../m4/ltsugar.m4'
> libtoolize: copying file '../m4/ltversion.m4'
> libtoolize: copying file '../m4/lt~obsolete.m4'
> configure.ac:11: installing '../build-aux/ar-lib'
> configure.ac:11: installing '../build-aux/compile'
> configure.ac:41: installing '../build-aux/config.guess'
> configure.ac:41: installing '../build-aux/config.sub'
> configure.ac:9: installing '../build-aux/install-sh'
> configure.ac:9: installing '../build-aux/missing'
> Makefile.am: installing '../build-aux/depcomp'
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '../build-aux'.
> libtoolize: copying file '../build-aux/ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, '../m4'.
> libtoolize: copying file '../m4/libtool.m4'
> libtoolize: copying file '../m4/ltoptions.m4'
> libtoolize: copying file '../m4/ltsugar.m4'
> libtoolize: copying file '../m4/ltversion.m4'
> libtoolize: copying file '../m4/lt~obsolete.m4'
> configure.ac:15: installing '../build-aux/compile'
> configure.ac:21: installing '../build-aux/missing'
> Makefile.am:93: warning: EXTRA_DIST multiply defined in condition TRUE ...
> Makefile.am:28: ... 'EXTRA_DIST' previously defined here
> Makefile.am: installing '../build-aux/depcomp'
> parallel-tests: installing '../build-aux/test-driver'
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '../build-aux'.
> libtoolize: copying file '../build-aux/ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, '../m4'.
> libtoolize: copying file '../m4/libtool.m4'
> libtoolize: copying file '../m4/ltoptions.m4'
> libtoolize: copying file '../m4/ltsugar.m4'
> libtoolize: copying file '../m4/ltversion.m4'
> libtoolize: copying file '../m4/lt~obsolete.m4'
> configure.ac:23: installing '../build-aux/compile'
> configure.ac:21: installing '../build-aux/missing'
> aminclude.am:35: error: DX_COND_doc does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:41: error: DX_COND_html does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:51: error: DX_COND_chm does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:55: error: DX_COND_chi does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:67: error: DX_COND_man does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:77: error: DX_COND_rtf does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:87: error: DX_COND_xml does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:97: error: DX_COND_ps does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:126: error: DX_COND_pdf does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> aminclude.am:155: error: DX_COND_latex does not appear in AM_CONDITIONAL
> Makefile.am:181:   'aminclude.am' included from here
> Makefile.am: installing '../build-aux/depcomp'
> configure.ac: installing '../build-aux/ylwrap'
> autoreconf: automake failed with exit status: 1
> dh_autoreconf: autoreconf -f -i returned exit code 1
> debian/rules:14: recipe for target 'build' failed
> make: *** [build] Error 2

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/singular_4.0.3-p1+ds-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837010: gnustep-base: FTBFS: Tests failures

[Lucas Nussbaum]

Source: gnustep-base
Version: 1.24.9-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> 
> Testing NSXMLParser.m...
> Running base/headers/NSXMLParser.m...
> Passed test: NSXMLParser.m:9 ... include of Foundation/NSXMLParser.h works
> Completed file:  NSXMLParser.m
> 
> Testing NSZone.m...
> Running base/headers/NSZone.m...
> Passed test: NSZone.m:9 ... include of Foundation/NSZone.h works
> Completed file:  NSZone.m
> 
> Testing Unicode.m...
> Running base/headers/Unicode.m...
> Passed test: Unicode.m:9 ... include of GNUstepBase/Unicode.h works
> Completed file:  Unicode.m
> debian/rules:166: recipe for target 'override_dh_auto_test' failed

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/gnustep-base_1.24.9-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837014: mono: FTBFS: build/profiles/basic.make:93: recipe for target 'build/deps/basic-profile-check.exe' failed

[Lucas Nussbaum]

Source: mono
Version: 4.2.1.102+dfsg2-8
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> make[3]: Entering directory '/<>/mono-4.2.1.102+dfsg2/runtime'
> d=`cd ../support && pwd`; \
> sed 
> 's,target="/usr/lib/libMonoPosixHelper.so",target="'$d'/libMonoPosixHelper.la",'
>  ../data/config > etc/mono/configt
> if test -z ""; then :; else \
>   sed 's,target="libgdiplus.so",target="",' etc/mono/configt > 
> etc/mono/configtt; \
>   mv -f etc/mono/configtt etc/mono/configt; fi
> mv -f etc/mono/configt etc/mono/config
> /bin/bash ../mkinstalldirs _tmpinst/bin
> mkdir -p -- _tmpinst/bin
> cp mono-wrapper _tmpinst/bin/mono
> echo '#! /bin/sh' > _tmpinst/bin/ilasm ; \
> r=`pwd`; m=`cd /<>/mono-4.2.1.102+dfsg2/mcs && pwd`; \
> echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/ilasm/ilasm.exe"'" "$@"' >> 
> _tmpinst/bin/ilasm ; \
> chmod +x _tmpinst/bin/ilasm
> echo '#! /bin/sh' > _tmpinst/bin/mcs ; \
> r=`pwd`; m=`cd /<>/mono-4.2.1.102+dfsg2/mcs && pwd`; \
> echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/build/mcs.exe"'" "$@"' 
> >> _tmpinst/bin/mcs ; \
> chmod +x _tmpinst/bin/mcs
> echo '#! /bin/sh' > _tmpinst/bin/dmcs ; \
> r=`pwd`; m=`cd /<>/mono-4.2.1.102+dfsg2/mcs && pwd`; \
> echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/build/mcs.exe -sdk:4"'" 
> "$@"' >> _tmpinst/bin/dmcs ; \
> chmod +x _tmpinst/bin/dmcs
> echo '#! /bin/sh' > _tmpinst/bin/al2 ; \
> r=`pwd`; m=`cd /<>/mono-4.2.1.102+dfsg2/mcs && pwd`; \
> echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/net_2_0/al.exe"'" "$@"' 
> >> _tmpinst/bin/al2 ; \
> chmod +x _tmpinst/bin/al2
> echo '#! /bin/sh' > _tmpinst/bin/al ; \
> r=`pwd`; m=`cd /<>/mono-4.2.1.102+dfsg2/mcs && pwd`; \
> echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/net_4_5/al.exe"'" "$@"' 
> >> _tmpinst/bin/al ; \
> chmod +x _tmpinst/bin/al
> if test -w /<>/mono-4.2.1.102+dfsg2/mcs; then :; else chmod -R +w 
> /<>/mono-4.2.1.102+dfsg2/mcs; fi
> cd /<>/mono-4.2.1.102+dfsg2/mcs && /usr/bin/make 
> --no-print-directory -s NO_DIR_CHECK=1 PROFILES='binary_reference_assemblies 
> net_4_5 xbuild_12 xbuild_14' CC='gcc' all-profiles
> mkdir -p -- build/deps
> build/profiles/basic.make:93: recipe for target 
> 'build/deps/basic-profile-check.exe' failed
> make[7]: *** [build/deps/basic-profile-check.exe] Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/mono_4.2.1.102+dfsg2-8_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837009: cheetah: FTBFS: debian/rules:20: *** no python implementation resolved from flavor "python$buildver". Stop.

[Lucas Nussbaum]

Source: cheetah
Version: 2.4.4-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>  fakeroot debian/rules binary
> test -x debian/rules
> dh_testroot
> dh_clean -k 
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_installdirs -A 
> mkdir -p "."
> mkdir -p debian/python-module-stampdir
> set -e; cd . && python2 setup.py build 
> --build-base="/<>/./build";
> running build
> running build_py
> running build_ext
> running build_scripts
> touch debian/python-module-stampdir/python-cheetah
> Adding cdbs dependencies to debian/python-cheetah.substvars
> dh_installdirs -ppython-cheetah \
>   
> set -e; cd . && python2 setup.py install 
> --root="/<>/debian/python-cheetah/" --install-layout=deb 
> --no-compile -O0 --single-version-externally-managed;
> running install
> running build
> running build_py
> running build_ext
> running build_scripts
> running install_lib
> creating /<>/debian/python-cheetah/usr
> creating /<>/debian/python-cheetah/usr/lib
> creating /<>/debian/python-cheetah/usr/lib/python2.7
> creating 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages
> creating 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> creating 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Tools
> copying build/lib.linux-x86_64-2.7/Cheetah/Tools/SiteHierarchy.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Tools
> copying build/lib.linux-x86_64-2.7/Cheetah/Tools/RecursiveNull.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Tools
> copying build/lib.linux-x86_64-2.7/Cheetah/Tools/CGITemplate.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Tools
> copying build/lib.linux-x86_64-2.7/Cheetah/Tools/__init__.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Tools
> copying build/lib.linux-x86_64-2.7/Cheetah/Tools/MondoReport.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Tools
> copying build/lib.linux-x86_64-2.7/Cheetah/Template.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/ImportManager.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/FileUtils.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/SettingsManager.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/DummyTransaction.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/ImportHooks.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/DirectiveAnalyzer.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/SourceReader.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/Version.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/NameMapper.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/Parser.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/CacheStore.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> copying build/lib.linux-x86_64-2.7/Cheetah/ErrorCatchers.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah
> creating 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Utils
> copying build/lib.linux-x86_64-2.7/Cheetah/Utils/WebInputMixin.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Utils
> copying build/lib.linux-x86_64-2.7/Cheetah/Utils/Indenter.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Utils
> copying build/lib.linux-x86_64-2.7/Cheetah/Utils/Misc.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Utils
> copying build/lib.linux-x86_64-2.7/Cheetah/Utils/statprof.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Utils
> copying build/lib.linux-x86_64-2.7/Cheetah/Utils/__init__.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Utils
> copying build/lib.linux-x86_64-2.7/Cheetah/Utils/htmlEncode.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Utils
> copying build/lib.linux-x86_64-2.7/Cheetah/Utils/htmlDecode.py -> 
> /<>/debian/python-cheetah/usr/lib/python2.7/dist-packages/Cheetah/Utils
> 

Bug#837011: ltrace: FTBFS: proc.c:245:3: error: 'readdir_r' is deprecated [-Werror=deprecated-declarations]

[Lucas Nussbaum]

Source: ltrace
Version: 0.7.3-5.1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> /bin/bash ../../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I../..  -I../../sysdeps/linux-gnu/x86  -I../../sysdeps/linux-gnu   
> -I../../sysdeps -I../..  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
> -Wsign-compare -Wfloat-equal -Wformat-security -Werror -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o proc.lo proc.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. 
> -I../../sysdeps/linux-gnu/x86 -I../../sysdeps/linux-gnu -I../../sysdeps 
> -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -Wfloat-equal 
> -Wformat-security -Werror -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -c proc.c  -fPIC 
> -DPIC -o .libs/proc.o
> proc.c: In function 'process_tasks':
> proc.c:245:3: error: 'readdir_r' is deprecated 
> [-Werror=deprecated-declarations]
>if (readdir_r(d, , ) != 0) {
>^~
> In file included from proc.c:31:0:
> /usr/include/dirent.h:183:12: note: declared here
>  extern int readdir_r (DIR *__restrict __dirp,
> ^
> cc1: all warnings being treated as errors
> Makefile:366: recipe for target 'proc.lo' failed
> make[5]: *** [proc.lo] Error 1

The full build log is available from:
   http://people.debian.org/~lucas/logs/2016/09/06/ltrace_0.7.3-5.1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837007: xfce4-radio-plugin: FTBFS: videodev2.h:2105:20: error: field 'timestamp' has incomplete type

[Lucas Nussbaum]

Source: xfce4-radio-plugin
Version: 0.5.1-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG 
> -DPACKAGE_LOCALE_DIR=\"/usr/share/locale\" -pthread 
> -I/usr/include/xfce4/libxfce4panel-1.0 -I/usr/include/gtk-2.0 
> -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ 
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16 
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
> -I/usr/include/freetype2 -I/usr/include/xfce4 -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/xfce4 
> -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
> -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
> -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 
> -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
> -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
> -I/usr/include/freetype2 -I/usr/include/xfce4 -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -std=c99 -g -O2 
> -fdebug-prefix-map=/<>=. -fPIE -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o xfce4_radio_plugin-v4l2.o `test -f 'v4l2.c' || 
> echo './'`v4l2.c
> In file included from v4l2.c:25:0:
> /usr/include/linux/videodev2.h:2105:20: error: field 'timestamp' has 
> incomplete type
>   struct timespec   timestamp;
> ^
> Makefile:501: recipe for target 'xfce4_radio_plugin-v4l2.o' failed
> make[3]: *** [xfce4_radio_plugin-v4l2.o] Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/xfce4-radio-plugin_0.5.1-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837005: mate-applets: FTBFS: ./cpufreq/src/cpufreq-monitor-libcpufreq.c:118: undefined reference to `cpupower_is_cpu_online'

[Lucas Nussbaum]

Source: mate-applets
Version: 1.14.1-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -g -O2 
> -fdebug-prefix-map=/<>=. -fPIE -fstack-protector-strong -Wformat 
> -Werror=format-security  -fPIE -pie -Wl,-z,relro -Wl,-z,now -o 
> mate-cpufreq-applet cpufreq-applet.o cpufreq-utils.o cpufreq-prefs.o 
> cpufreq-selector.o cpufreq-popup.o cpufreq-monitor.o 
> cpufreq-monitor-factory.o cpufreq-monitor-procfs.o cpufreq-monitor-sysfs.o 
> cpufreq-monitor-libcpufreq.o cpufreq-monitor-cpuinfo.o -lmate-panel-applet-4 
> -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject 
> -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lmate-desktop-2 
> -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject 
> -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
> -lstartup-notification-1 -lcpufreq -ldbus-glib-1 -ldbus-1 -lgobject-2.0 
> -lglib-2.0 
> libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security -fPIE -pie -Wl,-z 
> -Wl,relro -Wl,-z -Wl,now -o mate-cpufreq-applet cpufreq-applet.o 
> cpufreq-utils.o cpufreq-prefs.o cpufreq-selector.o cpufreq-popup.o 
> cpufreq-monitor.o cpufreq-monitor-factory.o cpufreq-monitor-procfs.o 
> cpufreq-monitor-sysfs.o cpufreq-monitor-libcpufreq.o 
> cpufreq-monitor-cpuinfo.o  -lmate-panel-applet-4 -lmate-desktop-2 -lgtk-3 
> -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo 
> -lgdk_pixbuf-2.0 -lgio-2.0 -lstartup-notification-1 -lcpufreq -ldbus-glib-1 
> -ldbus-1 -lgobject-2.0 -lglib-2.0
> cpufreq-monitor-libcpufreq.o: In function `cpufreq_monitor_libcpufreq_run':
> ./cpufreq/src/cpufreq-monitor-libcpufreq.c:118: undefined reference to 
> `cpupower_is_cpu_online'
> collect2: error: ld returned 1 exit status

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/mate-applets_1.14.1-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837006: gnome-python-desktop: FTBFS: /usr/share/cdbs/1/class/autotools.mk:44: *** no python implementation resolved from binary package "stamp-autotools". Stop.

[Lucas Nussbaum]

Source: gnome-python-desktop
Version: 2.32.0+dfsg-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>  debian/rules build
> test -x debian/rules
> mkdir -p "debian/build"
> CDBS WARNING:DEB_DH_BUILDDEB_ARGS is deprecated since 0.4.85
> set -e;   mv ./config.guess ./config.guess.cdbs-orig; cp --remove-destination 
> /usr/share/misc/config.guess ./config.guess;
> set -e;   mv ./config.sub ./config.sub.cdbs-orig; cp --remove-destination 
> /usr/share/misc/config.sub ./config.sub;
> dh_autoreconf 
> libtoolize: putting auxiliary files in '.'.
> libtoolize: copying file './ltmain.sh'
> libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
> libtoolize: and rerunning libtoolize and aclocal.
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> configure.ac:66: installing './compile'
> configure.ac:41: installing './missing'
> braseroburn/Makefile.am:1: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> braseroburn/Makefile.am: installing './depcomp'
> braseromedia/Makefile.am:1: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> evince/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
> (or '*_CPPFLAGS')
> evolution/Makefile.am:1: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> gnomeapplet/Makefile.am:1: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> gnomedesktop/Makefile.am:1: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> gnomekeyring/Makefile.am:1: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> gnomeprint/Makefile.am:2: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> gtksourceview/Makefile.am:3: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> gtop/Makefile.am:2: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or 
> '*_CPPFLAGS')
> mediaprofiles/Makefile.am:3: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> metacity/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' 
> (or '*_CPPFLAGS')
> nautilusburn/Makefile.am:1: warning: 'INCLUDES' is the old name for 
> 'AM_CPPFLAGS' (or '*_CPPFLAGS')
> rsvg/Makefile.am:3: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or 
> '*_CPPFLAGS')
> tests/Makefile.am:3: warning: shell echo $$PYTHONPATH: non-POSIX variable name
> tests/Makefile.am:3: (probably a GNU make extension)
> wnck/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or 
> '*_CPPFLAGS')
> touch debian/stamp-autotools-files
> /usr/share/cdbs/1/class/autotools.mk:44: *** no python implementation 
> resolved from binary package "stamp-autotools".  Stop.
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> Build finished at 2016-09-06T22:49:54Z

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/gnome-python-desktop_2.32.0+dfsg-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837004: installation-locale: FTBFS: no output file produced because warnings were issued

[Lucas Nussbaum]

Source: installation-locale
Version: 1.6
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> localedef -i C.UTF-8.in -f "UTF-8" ./C.UTF-8
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_CTYPE'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_NUMERIC'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_TIME'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_COLLATE'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_MONETARY'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_MESSAGES'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_PAPER'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_NAME'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_ADDRESS'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category `LC_TELEPHONE'
> LC_IDENTIFICATION: unknown standard `C@utf-8:2000' for category 
> `LC_IDENTIFICATION'
> no output file produced because warnings were issued
> Makefile:4: recipe for target 'C.UTF-8' failed
> make[1]: *** [C.UTF-8] Error 4

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/installation-locale_1.6_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837002: aweather: FTBFS: gps.h:1905:21: error: field 'real' has incomplete type

[Lucas Nussbaum]

Source: aweather
Version: 0.8.1-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> make[4]: Entering directory '/<>/src/plugins'
> ../../doltlibtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../..  
> -DPKGDATADIR="\"/usr/share/aweather\"" -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
> --std=gnu99 -DSYS_X11 -pthread -I/usr/include/grits 
> -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/gtk-2.0 
> -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ 
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16 
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> -I/usr/include/freetype2 -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
> alert_la-alert.lo `test -f 'alert.c' || echo './'`alert.c
> alert.c: In function 'msg_load_cap':
> alert.c:332:2: warning: this 'if' clause does not guard... 
> [-Wmisleading-indentation]
>   if (!id) return FALSE; id++;
>   ^~
> alert.c:332:25: note: ...this statement, but the latter is misleadingly 
> indented as if it is guarded by the 'if'
>   if (!id) return FALSE; id++;
>  ^~
> ../../doltlibtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../..  
> -DPKGDATADIR="\"/usr/share/aweather\"" -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
> --std=gnu99 -DSYS_X11 -pthread -I/usr/include/grits 
> -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/gtk-2.0 
> -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ 
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16 
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> -I/usr/include/freetype2 -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
> alert_la-alert-info.lo `test -f 'alert-info.c' || echo './'`alert-info.c
> ../../doltlibtool --tag=CC   --mode=link gcc -Wall --std=gnu99 -DSYS_X11 
> -pthread -I/usr/include/grits -I/usr/include/libsoup-2.4 
> -I/usr/include/libxml2 -I/usr/include/gtk-2.0 
> -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ 
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16 
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 
> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> -I/usr/include/freetype2 -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -shared -module 
> -avoid-version  -Wl,--as-needed -Wl,-z,relro -o alert.la -rpath 
> /usr/lib/x86_64-linux-gnu/aweather alert_la-alert.lo alert_la-alert-info.lo 
> -lgrits -lX11 -lGL -lGLU -Wl,--export-dynamic -lgmodule-2.0 -pthread 
> -lsoup-2.4 -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo 
> -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 
> -lglib-2.0 -lfontconfig -lfreetype -lgrits -lX11 -lGL -lGLU 
> -Wl,--export-dynamic -lgmodule-2.0 -pthread -lsoup-2.4 -lgtk-x11-2.0 
> -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 
> -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype
> libtool: link: gcc -shared  -fPIC -DPIC  .libs/alert_la-alert.o 
> .libs/alert_la-alert-info.o   -lgrits -lX11 -lGL -lGLU -lgmodule-2.0 
> -lsoup-2.4 -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo 
> -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 
> -lglib-2.0 -lfontconfig /usr/lib/x86_64-linux-gnu/libfreetype.so  -pthread 
> -O2 -Wl,--as-needed -Wl,-z -Wl,relro -Wl,--export-dynamic -pthread 
> -Wl,--export-dynamic -pthread   -pthread -Wl,-soname -Wl,alert.so -o 
> .libs/alert.so
> libtool: link: ( cd ".libs" && rm -f "alert.la" && ln -s "../alert.la" 
> "alert.la" )
> ../../doltlibtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../..  
> -DPKGDATADIR="\"/usr/share/aweather\"" -I../../src -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall --std=gnu99 -DSYS_X11 -pthread -I/usr/include/grits 
> -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/gtk-2.0 
> -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ 
> -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
> 

Bug#836998: dbus-sharp-glib: FTBFS: mdoc: Could not find file "/etc/localtime"

[Lucas Nussbaum]

Source: dbus-sharp-glib
Version: 0.6.0-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> make[3]: Entering directory '/<>'
> make[3]: Nothing to be done for 'all-am'.
> make[3]: Leaving directory '/<>'
> make[2]: Leaving directory '/<>'
> mkdir -p /<>/doc;
> for LIB in /<>/src/dbus-sharp-glib.dll; do \
>   mdoc update \
>   -fno-assembly-versions \
>   --out=/<>/doc \
>   $LIB; \
>   mdoc assemble \
>   --format ecma \
>   --out ${LIB%.dll} \
>   /<>/doc; \
> done
> New Type: DBus.BusG
> Member Added: public static void Init ();
> Member Added: public static void Init (DBus.Connection conn);
> Namespace Directory Created: DBus
> New Namespace File: DBus
> Members Added: 2, Members Deleted: 0
> mdoc: Could not find file "/etc/localtime"
> See `mdoc help' for more information.
> debian/rules:16: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/dbus-sharp-glib_0.6.0-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837000: kerberos-configs: FTBFS: Undefined subroutine ::read_config called at ./genblob line 9.

[Lucas Nussbaum]

Source: kerberos-configs
Version: 2.3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
>  fakeroot debian/rules binary
> ./genblob >tmp & tmp config-blob
> Undefined subroutine ::read_config called at ./genblob line 9.
> debian/rules:17: recipe for target 'config-blob' failed
> make: *** [config-blob] Error 2

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/kerberos-configs_2.3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#837001: naspro-core: FTBFS: fs.c:106:3: error: 'readdir_r' is deprecated [-Werror=deprecated-declarations]

[Lucas Nussbaum]

Source: naspro-core
Version: 0.5.1-2
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> /bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I../..  -I../../include -I../../src -Wdate-time -D_FORTIFY_SOURCE=2 
> -pedantic -Wall -Werror -pthread -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -c -o fs.lo fs.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include 
> -I../../src -Wdate-time -D_FORTIFY_SOURCE=2 -pedantic -Wall -Werror -pthread 
> -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
> -Wformat -Werror=format-security -c fs.c  -fPIC -DPIC -o .libs/fs.o
> fs.c: In function 'nacore_fs_dir_get_next_entry':
> fs.c:106:3: error: 'readdir_r' is deprecated [-Werror=deprecated-declarations]
>readdir_r(dir->dir, (struct dirent *)ret, );
>^
> In file included from fs.c:27:0:
> /usr/include/dirent.h:183:12: note: declared here
>  extern int readdir_r (DIR *__restrict __dirp,
> ^
> cc1: all warnings being treated as errors
> Makefile:398: recipe for target 'fs.lo' failed
> make[5]: *** [fs.lo] Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/09/06/naspro-core_0.5.1-2_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#836999: strace: FTBFS: ../btrfs.c:68:8: error: redefinition of 'struct btrfs_ioctl_defrag_range_args'

[Lucas Nussbaum]

Source: strace
Version: 4.12-3
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160906 qa-ftbfs
Justification: FTBFS on amd64

Hi,

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

Relevant part (hopefully):
> gcc -DHAVE_CONFIG_H   -I./linux/x86_64 -I../linux/x86_64 -I./linux -I../linux 
> -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wwrite-strings 
> -Wsign-compare  -g -O2 -fdebug-prefix-map=/<>=. -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -O2 -MT 
> strace-btrfs.o -MD -MP -MF .deps/strace-btrfs.Tpo -c -o strace-btrfs.o `test 
> -f 'btrfs.c' || echo '../'`btrfs.c
> ../btrfs.c:68:8: error: redefinition of 'struct btrfs_ioctl_defrag_range_args'
>  struct btrfs_ioctl_defrag_range_args {
> ^
> In file included from ../btrfs.c:36:0:
> /usr/include/linux/btrfs.h:496:8: note: originally defined here
>  struct btrfs_ioctl_defrag_range_args {
> ^
> Makefile:2619: recipe for target 'strace-btrfs.o' failed
> make[3]: *** [strace-btrfs.o] Error 1

The full build log is available from:
   http://people.debian.org/~lucas/logs/2016/09/06/strace_4.12-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#836997: i965-va-driver: Missing i965-va-driver 1.7.2-1 for amd64

[Ben Caradoc-Davies]

Package: i965-va-driver
Version: 1.7.2-1
Severity: normal

Dear Maintainer,

i965-va-driver 1.7.2-1 for amd64 is missing. Noticed on multiarch where it
causes i386 to be held back:

The following packages have been kept back:
   i965-va-driver:i386 (1.7.1-1 => 1.7.2-1)

The build looks OK:
https://buildd.debian.org/status/package.php?p=intel-vaapi-
driver=unstable
https://buildd.debian.org/status/logs.php?arch=amd64=intel-vaapi-
driver=1.7.2-1

PTS confirms that it is held back from testing migration because: "missing
build on amd64: i965-va-driver (from 1.7.1-1)":
https://packages.qa.debian.org/i/intel-vaapi-driver.html

For some reason, the amd64 package for 1.7.2-1 is not yet in unstable.

Kind regards,
Ben.



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

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

Bug#836962: Uninstallable in testing when default-libmysqlclient-dev is installed

[Enrico Zini]

On Wed, Sep 07, 2016 at 06:09:16PM +0200, Sebastiaan Couwenberg wrote:

> I'm very disappointed that the introduction of the
> default-libmysqlclient-dev packages now immediately results in RC bugs.
> 
> For now I've changed the dependency to default-libmysqlclient-dev, but
> I'm considering dropping MySQL/MariaDB support because of my
> disappointment in its maintainers.

Hi, thanks for dealing with this so quickly.

Note that it might have been a misjudgement of mine to set severity of
this bug to serious, rather than a fault of the mysql/mariadb
mainatainers.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#836996: transition: evolution-data-server 3.21.x

[Michael Biebl]

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

Hi,

for the upcoming GNOME 3.22 release we have the bi-anual soname bumps in
evolution-data-server.

Updating evolution-data-server to 3.21.x means a soname bump for
libcamel and libedataserver.

We've uploaded evolution-data-server 3.21.91-1 to experimental and the
package built successfully everywhere. We also did a rebuild of all
rdeps on deb-o-matic and there were no build failures aside from
evolution, which will get a sourceful upload for 3.22 anyway.

The auto-tracker is at [1] and looks fine.

Please let us know when we can start with the transition.


Regards,
Michael

[1] https://release.debian.org/transitions/html/auto-evolution-data-server.html

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

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

Bug#836940: [buildd-tools-devel] Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[Santiago Vila]

On Wed, 7 Sep 2016, Markus Koschany wrote:

> Now we all agree that a package that fails to build
> on the official buildd network is RC buggy. But what about packages that
> neither fail there nor locally in a clean cowbuilder environment but
> under some obscure circumstances in a local sbuild environment?

For the record: This is a false dichotomy, because xmlgraphics-commons
didn't fail in the official buildds. it didn't fail in a
what-you-call-clean-but-it-was-not-really-clean cowbuilder
environment, but the circumstances in which it failed were not
obscrure at all (as explained).

It seems to me that you are looking for a generic passport to
downgrade FTBFS bugs. Please don't put policy violations and
bugs that we still don't know how to reproduce in the same bag.

Thanks.

Bug#836940: [buildd-tools-devel] Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[Markus Koschany]

On 07.09.2016 23:24, Mattia Rizzolo wrote:
> Pbuilder (and therefore cowbuilder) already use --variant=buildd
> 
> That afaik is --variant=minbase + build-essential.
> 
> I'm not sure why you still get gnupg installed.
> 
> Btw what version are you using (of cowbuilder and pbuilder)?

I'm using the latest packages from sid (cowbuilder 0.80, pbuilder
0.226). I'm not sure but I believe exporting
DEBOOTSTRAPOPTS=--variant=buildd solved the issue for me. GnuPG is no
longer installed by default. I'm using a slightly modified version of
Ubuntu's .pbuilderrc which I have once copied from

https://wiki.ubuntu.com/PbuilderHowto

I'll check again tomorrow if gnupg will be installed without passing
this option to pbuilder. It may well be that I did something wrong a few
hours ago.




signature.asc
Description: OpenPGP digital signature

Bug#836917: transition: openmpi

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 07/09/16 10:25, Bas Couwenberg wrote:
> It sadly seems to be the season of uncoordinated transitions, with some
> maintainers not learning for their past mistakes. Very disappointing.

It's already started, so let's tag it as such.

I have urgented proj so that e.g. vtk6 can migrate and doesn't get tangled with
this transition.

Cheers,
Emilio

Bug#836995: texlive-base: fails to upgrade wheezy -> jessie -> stretch

[Andreas Beckmann]

Package: texlive-base
Version: 2016.20160819-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + tex4ht

Hi,

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

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

  Selecting previously unselected package texlive-base.
  Preparing to unpack .../texlive-base_2016.20160819-2_all.deb ...
  Unpacking texlive-base (2016.20160819-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/texlive-base_2016.20160819-2_all.deb (--unpack):
   trying to overwrite '/usr/share/texlive/tlpkg/TeXLive/TLConfFile.pm', which 
is also in package texlive-common 2012.20120611-5
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)


Please add appropriate Breaks+Replaces against texlive-common/wheezy
which may have survived some wheezy->jessie upgrades.


cheers,

Andreas


tex4ht_20160814-1.log.gz
Description: application/gzip

Bug#823574: knot: fails to upgrade from 'jessie': Error: syntax error (file '/var/backups/knot/20160503-122201/knot.conf', line 6)

[Andreas Beckmann]

Followup-For: Bug #823574

Please update the package in jessie-backports to a fixed version.

Thanks


Andreas

Bug#836987: RFS: hoichess/0.19.0-2 [QA]

[Eriberto]

Control: tag 836987 moreinfo

Hi Jeremy,

I did an upload for this package some hours ago and I can sponsor this
package again. A question: will you really put this package in Collab
Maint?

Regards,

Eriberto


2016-09-07 17:30 GMT-03:00 Jeremy Bicha :
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "hoichess"
>
> * Package name: hoichess
> * Version : 0.19.0-2
> * Section : games
>
> It builds those binary packages:
>
>hoichess   - xboard compatible chess engine to play chess with
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/hoichess
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/main/h/hoichess/hoichess_0.19.0-2.dsc
>
> More information about hello can be obtained from https://www.example.com.
>
> Changes since the last upload:
>
>  * QA upload
>  * Suggest instead of Recommend xboard | scid. Closes: #820461
>  * Suggest gnome-chess as an alternative too
>  * Import to collab-maint and set Vcs fields
>
>
> Thanks,
> Jeremy Bicha
>

Bug#836940: [buildd-tools-devel] Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[Thorsten Glaser]

Mattia Rizzolo dixit:

>I'm not sure why you still get gnupg installed.
>
>Btw what version are you using (of cowbuilder and pbuilder)?

I just installed (on an up-to-date sid/x32 system with latest
cowbuilder/pbuilder) a fresh sid chroot (from a local mirror
that’s updated daily) and get no gnupg. The full package list:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  adduser3.115all  add and remove 
users and groups
ii  apt1.3~rc4  i386 commandline 
package manager
ii  aptitude   0.8.3-1  i386 terminal-based 
package manager
ii  aptitude-common0.8.3-1  all  architecture 
independent files for the aptitude p
ii  base-files 9.6  i386 Debian base system 
miscellaneous files
ii  base-passwd3.5.40   i386 Debian base system 
master password and group file
ii  bash   4.3-15   i386 GNU Bourne Again 
SHell
ii  binutils   2.27-8   i386 GNU assembler, 
linker and binary utilities
ii  bsdutils   1:2.28.1-1   i386 basic utilities 
from 4.4BSD-Lite
ii  build-essential12.2 i386 Informational list 
of build-essential packages
ii  bzip2  1.0.6-8  i386 high-quality 
block-sorting file compressor - util
ii  coreutils  8.25-2   i386 GNU core utilities
ii  cowdancer  0.80 i386 Copy-on-write 
directory tree utility
ii  cpp4:6.1.1-1i386 GNU C preprocessor 
(cpp)
ii  cpp-6  6.2.0-3  i386 GNU C preprocessor
ii  dash   0.5.8-2.3i386 POSIX-compliant 
shell
ii  debconf1.5.59   all  Debian 
configuration management system
ii  debian-archive-keyring 2014.3   all  GnuPG archive keys 
of the Debian archive
ii  debianutils4.8  i386 Miscellaneous 
utilities specific to Debian
ii  diffutils  1:3.5-1  i386 File comparison 
utilities
ii  dpkg   1.18.10  i386 Debian package 
management system
ii  dpkg-dev   1.18.10  all  Debian package 
development tools
ii  e2fslibs:i386  1.43.3-1 i386 ext2/ext3/ext4 
file system libraries
ii  e2fsprogs  1.43.3-1 i386 ext2/ext3/ext4 
file system utilities
ii  eatmydata  105-3all  Library and 
utilities designed to disable fsync a
ii  fakeroot   1.21-2   i386 tool for 
simulating superuser privileges
ii  findutils  4.6.0+git+201607 i386 utilities for 
finding files--find, xargs
ii  g++4:6.1.1-1i386 GNU C++ compiler
ii  g++-6  6.2.0-3  i386 GNU C++ compiler
ii  gcc4:6.1.1-1i386 GNU C compiler
ii  gcc-4.9-base:i386  4.9.4-2  i386 GCC, the GNU 
Compiler Collection (base package)
ii  gcc-5-base:i3865.4.1-2  i386 GCC, the GNU 
Compiler Collection (base package)
ii  gcc-6  6.2.0-3  i386 GNU C compiler
ii  gcc-6-base:i3866.2.0-3  i386 GCC, the GNU 
Compiler Collection (base package)
ii  gpgv   2.1.15-2 i386 GNU privacy guard 
- signature verification tool
ii  grep   2.25-6   i386 GNU grep, egrep 
and fgrep
ii  gzip   1.6-5i386 GNU compression 
utilities
ii  hostname   3.18 i386 utility to 
set/show the host name or domain name
ii  init-system-helpers1.42 all  helper tools for 
all init systems
ii  initscripts2.88dsf-59.8 i386 scripts for 
initializing and shutting down the sy
ii  insserv1.14.0-5.4   i386 boot sequence 
organizer using LSB init.d script d
ii  libacl1:i386   2.2.52-3 i386 Access control 
list shared library
ii  libapt-pkg5.0:i386 1.3~rc4  i386 package management 
runtime library
ii  libasan3:i386  6.2.0-3  i386 AddressSanitizer 
-- a fast memory error detector
ii  

Bug#808312: chemps2: fails to upgrade from 'testing' - trying to overwrite /usr/share/man/man1/chemps2.1.gz

[Andreas Beckmann]

Followup-For: Bug #808312

Hi,

the fix seems to have disappeared, as can be seen in upgrades from
jessie-backports to stretch failing:

  Preparing to unpack .../chemps2_1.8-1_amd64.deb ...
  Unpacking chemps2 (1.8-1) over (1.6-1~bpo80+1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/chemps2_1.8-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/chemps2.1.gz', which is also in 
package libchemps2-1 1.6-1~bpo80+1


Andreas


chemps2_1.8-1.log.gz
Description: application/gzip

Bug#836993: qgis: fails to upgrade from 'jessie': dpkg-divert: error: rename involves overwriting `/usr/bin/qgis'

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Andreas,

Thanks for your work on piuparts.

I've moved the diversion removal to postinst per your suggestion, thanks!

A new upload to unstable will follow shortly.

Kind Regards,

Bas

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

Bug#828593: virtualbox: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-06-26 12:24:40 [+0200], Kurt Roeckx wrote:
> If you have problems making things work, feel free to contact us.

HALP!

It builds against old & new ssl and I am proud what I managed in
rdssl_cert_to_rkey(). However they dereference
EVP_MD->required_pkey_type which vanished in 1.1 and I have no idea what
it was and its purpose was. They don't even assign anything to it in
1.0.2h.

> Kurt

Sebastian
>From 0e3d6cc69959fdf4f4fd56f65353b76897c0daad Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Wed, 7 Sep 2016 20:22:54 +
Subject: [PATCH] virtualbox 5.1.4: get it built against openssl-1.1

Signed-off-by: Sebastian Andrzej Siewior 
---
 src/VBox/RDP/client-1.8.3/ssl.c| 70 +-
 src/VBox/Runtime/VBox/VBoxRTDeps.cpp   | 14 +++---
 src/VBox/Runtime/common/crypto/pkix-verify.cpp | 46 +++--
 3 files changed, 83 insertions(+), 47 deletions(-)

diff --git a/src/VBox/RDP/client-1.8.3/ssl.c b/src/VBox/RDP/client-1.8.3/ssl.c
index dac5511..bd207d5 100644
--- a/src/VBox/RDP/client-1.8.3/ssl.c
+++ b/src/VBox/RDP/client-1.8.3/ssl.c
@@ -97,7 +97,7 @@ rdssl_rsa_encrypt(uint8 * out, uint8 * in, int len, uint32 modulus_size, uint8 *
 		  uint8 * exponent)
 {
 	BN_CTX *ctx;
-	BIGNUM mod, exp, x, y;
+	BIGNUM *mod, *exp, *x, *y;
 	uint8 inr[SEC_MAX_MODULUS_SIZE];
 	int outlen;
 
@@ -107,24 +107,24 @@ rdssl_rsa_encrypt(uint8 * out, uint8 * in, int len, uint32 modulus_size, uint8 *
 	reverse(inr, len);
 
 	ctx = BN_CTX_new();
-	BN_init();
-	BN_init();
-	BN_init();
-	BN_init();
-
-	BN_bin2bn(modulus, modulus_size, );
-	BN_bin2bn(exponent, SEC_EXPONENT_SIZE, );
-	BN_bin2bn(inr, len, );
-	BN_mod_exp(, , , , ctx);
-	outlen = BN_bn2bin(, out);
+	mod = BN_new();
+	exp = BN_new();
+	x = BN_new();
+	y = BN_new();
+
+	BN_bin2bn(modulus, modulus_size, mod);
+	BN_bin2bn(exponent, SEC_EXPONENT_SIZE, exp);
+	BN_bin2bn(inr, len, x);
+	BN_mod_exp(y, x, exp, mod, ctx);
+	outlen = BN_bn2bin(y, out);
 	reverse(out, outlen);
 	if (outlen < (int) modulus_size)
 		memset(out + outlen, 0, modulus_size - outlen);
 
-	BN_free();
-	BN_clear_free();
-	BN_free();
-	BN_free();
+	BN_free(y);
+	BN_clear_free(x);
+	BN_free(exp);
+	BN_free(mod);
 	BN_CTX_free(ctx);
 }
 
@@ -149,18 +149,25 @@ rdssl_cert_to_rkey(RDSSL_CERT * cert, uint32 * key_len)
 	EVP_PKEY *epk = NULL;
 	RDSSL_RKEY *lkey;
 	int nid;
+	X509_PUBKEY *x509_pk;
+	X509_ALGOR *algor;
+	const ASN1_OBJECT *alg_obj;
 
 	/* By some reason, Microsoft sets the OID of the Public RSA key to
 	   the oid for "MD5 with RSA Encryption" instead of "RSA Encryption"
 
 	   Kudos to Richard Levitte for the following (. intiutive .) 
 	   lines of code that resets the OID and let's us extract the key. */
-	nid = OBJ_obj2nid(cert->cert_info->key->algor->algorithm);
+
+	x509_pk = X509_get_X509_PUBKEY(cert);
+	X509_PUBKEY_get0_param(NULL, NULL, NULL, , x509_pk);
+	X509_ALGOR_get0(_obj, NULL, NULL, algor);
+
+	nid = OBJ_obj2nid(alg_obj);
 	if ((nid == NID_md5WithRSAEncryption) || (nid == NID_shaWithRSAEncryption))
 	{
 		DEBUG_RDP5(("Re-setting algorithm type to RSA in server certificate\n"));
-		ASN1_OBJECT_free(cert->cert_info->key->algor->algorithm);
-		cert->cert_info->key->algor->algorithm = OBJ_nid2obj(NID_rsaEncryption);
+		X509_ALGOR_set0(algor, OBJ_nid2obj(NID_rsaEncryption), 0, NULL);
 	}
 	epk = X509_get_pubkey(cert);
 	if (NULL == epk)
@@ -203,21 +210,37 @@ rdssl_rkey_free(RDSSL_RKEY * rkey)
 	RSA_free(rkey);
 }
 
+#if OPENSSL_VERSION_NUMBER < 0x1010
+static inline void RSA_get0_key(const RSA *r, const BIGNUM **n,
+const BIGNUM **e, const BIGNUM **d)
+{
+	if (n != NULL)
+		*n = r->n;
+	if (e != NULL)
+		*e = r->e;
+	if (d != NULL)
+		*d = r->d;
+}
+#endif
+
 /* returns error */
 int
 rdssl_rkey_get_exp_mod(RDSSL_RKEY * rkey, uint8 * exponent, uint32 max_exp_len, uint8 * modulus,
 		   uint32 max_mod_len)
 {
 	int len;
+	const BIGNUM *e, *n;
+
+	RSA_get0_key(rkey, , , NULL);
 
-	if ((BN_num_bytes(rkey->e) > (int) max_exp_len) ||
-	(BN_num_bytes(rkey->n) > (int) max_mod_len))
+	if ((BN_num_bytes(e) > (int) max_exp_len) ||
+	(BN_num_bytes(n) > (int) max_mod_len))
 	{
 		return 1;
 	}
-	len = BN_bn2bin(rkey->e, exponent);
+	len = BN_bn2bin(e, exponent);
 	reverse(exponent, len);
-	len = BN_bn2bin(rkey->n, modulus);
+	len = BN_bn2bin(n, modulus);
 	reverse(modulus, len);
 	return 0;
 }
@@ -238,8 +261,5 @@ void
 rdssl_hmac_md5(const void *key, int key_len, const unsigned char *msg, int msg_len,
 	   unsigned char *md)
 {
-	HMAC_CTX ctx;
-	HMAC_CTX_init();
 	HMAC(EVP_md5(), key, key_len, msg, msg_len, md, NULL);
-	HMAC_CTX_cleanup();
 }
diff --git a/src/VBox/Runtime/VBox/VBoxRTDeps.cpp b/src/VBox/Runtime/VBox/VBoxRTDeps.cpp
index ddfccec..fa19fa7 100644
--- a/src/VBox/Runtime/VBox/VBoxRTDeps.cpp
+++ b/src/VBox/Runtime/VBox/VBoxRTDeps.cpp
@@ -76,26 +76,28 @@ PFNRT g_VBoxRTDeps[] =
 (PFNRT)i2d_X509,
 (PFNRT)i2d_X509,
 (PFNRT)i2d_PublicKey,
+#if 

Bug#836720: nslcd should recommend ca-certificates

[Arthur de Jong]

Control: tags -1 + pending

On Mon, 2016-09-05 at 05:21 +, Mathias Gibbens wrote:
> During installation nslcd failed to start, and I saw this error in
> the log:
> 
> > connection daemon: nslcdnslcd: /etc/nslcd.conf:28: tls_cacertfile:
> > error accessing /etc/ssl/certs/ca-certificates.crt: No such file or
> > directory
> 
> Installing the ca-certificates package created the ca-
> certificates.crt file which is expected by the default configuration
> of nslcd. I also tested installing nslcd on another identically
> configured test server, but purposefully installed the ca-
> certificates package before installing nslcd. That install finished
> without issue.
> 
> I think nslcd should recommend the ca-certificates package.

Thanks for pointing this out.

The next upload will add a recommends on ca-certificates. The added
checking of tls_cacertfile in 0.9.7 with the change for #750949
triggered this.

Thanks,

-- 
-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


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

Bug#836994: mate-panel: get wnck-applet underallocation notification all the time in journalctl

[shirish शिरीष]

Package: mate-panel
Version: 1.14.2-1
Severity: normal

Dear Maintainer,

Was running journalctl -f to see something else and came across the following -

Sep 08 02:58:25 debian wnck-applet[4205]: gtk_widget_size_allocate():
attempt to underallocate WnckTasklist's child GtkToggleButton
0x55a558d23e40. Allocation is 235x24, but minimum required size is
56x28.

However bigger I do the size allocation, it still is less. Hopefully
something can be done to fix it.

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

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

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.23-5
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libdbus-1-3  1.10.10-1
ii  libdbus-glib-1-2 0.106-1
ii  libdconf10.26.0-1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.49.6-1
ii  libgtk-3-0   3.21.5-3
ii  libice6  2:1.0.9-1+b1
ii  libmate-desktop-2-17 1.14.1-1
ii  libmate-menu21.14.0-1
ii  libmate-panel-applet-4-1 1.14.2-1
ii  libmateweather1  1.14.1-1
ii  libpango-1.0-0   1.40.2-1
ii  libpangocairo-1.0-0  1.40.2-1
ii  librsvg2-2   2.40.16-1
ii  libsm6   2:1.2.2-1+b1
ii  libstartup-notification0 0.12-4
ii  libwnck-3-0  3.20.1-1
ii  libx11-6 2:1.6.3-1
ii  libxau6  1:1.0.8-1
ii  libxrandr2   2:1.5.0-1
ii  mate-desktop 1.14.1-1
ii  mate-menus   1.14.0-1
ii  mate-panel-common1.14.2-1
ii  mate-polkit  1.14.0-1
ii  menu-xdg 0.5

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information


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

Bug#836940: [buildd-tools-devel] Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[Mattia Rizzolo]

Pbuilder (and therefore cowbuilder) already use --variant=buildd

That afaik is --variant=minbase + build-essential.

I'm not sure why you still get gnupg installed.

Btw what version are you using (of cowbuilder and pbuilder)?

On Wed, 7 Sep 2016, 11:19 p.m. Thorsten Glaser,  wrote:

> Markus Koschany dixit:
>
> >Thanks. Could we make these variants the default in cowbuilder?
>
> Unsure, people *can* use cowbuilder to create normal chroots
> for use, just like schroot.
>
> One thing we can do is to document this better in the cowbuilder
> manpage (currently only in pbuilder’s at all, and IMHO it belongs
> mentioned in the --create option).
>
> Or add a --variant to both pbuilder and cowbuilder that gets
> mapped to --debootstraptoptions --variant, and make --create
> error out if it’s not given.
>
> One more problem with this is that alternative debootstraps
> can be used, which may not have this option. So if we do the
> latter, it can only fire with --debootstrap debootstrap (or
> some variant of it… remember it’s just a script that can be
> renamed…).
>
> bye,
> //mirabilos
> --
> Stéphane, I actually don’t block Googlemail, they’re just too utterly
> stupid to successfully deliver to me (or anyone else using Greylisting
> and not whitelisting their ranges). Same for a few other providers such
> as Hotmail. Some spammers (Yahoo) I do block.
>

Bug#836940: [buildd-tools-devel] Bug#836940: cowbuilder, sbuild: should behave identically in regard to default gnupg installation

[Santiago Vila]

On Wed, 7 Sep 2016, Markus Koschany wrote:

> But what about packages that
> neither fail there nor locally in a clean cowbuilder environment but
> under some obscure circumstances in a local sbuild environment?

Excuse me? A chroot without gnupg is now called "obscure circumstances
in a local sbuild environment"? I find such expression sligthly
offensive and unrespectful, even more than raising once the severity
of the bug to match current practice (with a reminder of what current
practice is).

I said the way to reproduce it from the very beginning: A chroot
without gnupg. The patch clearly added gnupg to build-depends.
The error message said 'Cannot run program "gpg"'.

But now this is "obscure circumstances", as if I had not given enough
information to reproduce the bug.

The only thing I didn't do was to attach a full build log, because I
naively thought that the error message, the patch, the bug title and
the explanation was more than enough to reproduce the bug.

Why you apparently refused to use all this information when trying to
reproduce the bug is still a mystery to me.

Bug#836992: Enable CRL verification for TLS

[Christian Schrötter]

Source: munin
Version: 2.0.25-2
Severity: wishlist
Tags: upstream

Please enable CRL verification for TLS connections. There should be a
configuration option to enable it for server/client certificates.
Currently it's impossible to revoke certificates which are used for
Munin within a TLS setup.

The following page should help to implement it:

http://search.cpan.org/~mikem/Net-SSLeay-1.78/lib/Net/SSLeay.pod#Certificate_verification_and_Certificate_Revocation_Lists_(CRLs)

Bug#836942: transition: glew

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 07/09/16 14:15, Matteo F. Vescovi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I'm filing this bug for a new transition of glew package.
> 
> On July 24, 2016 the 2.0.0 actual stable version has been released by
> upstream.
> 
> On September 05, 2016 a testing-purpose package has been uploaded to
> experimental and it was tested building all its 73 reverse dependencies
> on the Deb-o-Matic infrastructure on amd64 architecture.
> 
> Following the auto-glew checklist[1], here is the list of source
> packages depending on glew and the results of the builds:

> Few packages are FTBFS, but only those (4) marked with [G] fail for some
> possible issues with GLEW.

Go ahead.

Cheers,
Emilio

Bug#833054: e2fsprogs: fsck.ext4 does not repair filesystem

[ael]

On Sun, Jul 31, 2016 at 03:14:28PM -0400, Theodore Ts'o wrote:
> 
> My suggestion at this point is to do an image copy of the entire
> contents of the sdhc card using either dd or ddrescue, to a known-good
> hard drive, and then run fsck.ext4 on that that image copy of your
> file system.  I suspect the root cause of this is simple hardware
> failure of the sdhc card.  So doing an image copy is a good idea
> before you do anything else, since it reduces the risk of (further)
> data loss.

First my apologies for the long silence: I was away from home.

I have done as you suggested. Taken an image of the sdhc card (on
another machine) and written that to a file (as it happens on an
usbstick). I then ran fsck.ext4 which claimed to correct a problem.

Next I loop-mounted that image. I also ran fsck.ext4 on the sdhc card
on the other machine) which similarly claimed to fix a problem and then
also mounted that.

I then tested using rsync as:

rsync -na /mnt/testing/ /sdhc/
  ^   ^
  |   |
loop mounted image   faulty card

That is I asked rsync to do a dry run copy from the loop mounted image to the 
card
so that it would read the image filesystem and not write to the card.

On a subset of files, I saw the warnings: Structure needs cleaning (117)
and /var/log/messages included 
   EXT4-fs error: 32 callbacks suppressed
Just to confirm, I used a simple cat of one of the problem files:-

# cat /mnt/testing/lost+found/#528000: Structure needs cleaning

So it seems that fsck.ext4 is unable to correct the problems even on the
image, although it claims to have done so.

It is possible that the original problem with the card was perhaps a
hardware fault (I have mentioned that it occasionally gets disturbed in
its slot), but whatever happened the current state of the file system
is confusing fsck.ext4. Or so it seems to me.

> 
> At this point, unless you can replicate the problem after copying the
> file system image off the sdhc to something more reliable (and in
> particular, cheap sd cards in the checkout counter line of "The Micro
> Center", or deep discount cards purchased from a direct-from-a-no-name-
> Shenzhen manufacturer don't count as reliable), I very much doubt it
> is a software bug, but rather a hardware issue.

So yes, I can replicate the problem after copying: I am satisfied that
the usbstick is fine, but I can do similar tests using other disk
hardware if you remain suspicious.

Of course, I can just reformat the card, and I am confident that it will
then work, but this looks like an opportunity to uncover a "feature"
lurking somewhere. I imagine that you will ask for an dumpe2fs run next?


Thanks for the help so far.