Bug#784798: Bug #784798: still requires dependency on specific version

[Mikhail Yakshin]

Dear TANIGUCHI Takaki,

I'd like to report that dependency on botocore introduced in
awscli-1.9.9-2 doesn't seem to be enough. In fact, I have installed

python-botocore = 1.3.9.-1
python3-botocore = 0.81.0-1

and awscli still fails to start with the following traceback:

Traceback (most recent call last):
 File "/usr/bin/aws", line 19, in 
   import awscli.clidriver
 File "/usr/share/awscli/awscli/clidriver.py", line 24, in 
   from botocore.client import Config
ImportError: cannot import name 'Config'

After I've upgraded everything to be

python-botocore = 1.3.9.-1
python3-botocore = 1.3.9.-1

I'm getting the following:

Traceback (most recent call last):
 File "/usr/bin/aws", line 27, in 
   sys.exit(main())
 File "/usr/bin/aws", line 23, in main
   return awscli.clidriver.main()
 File "/usr/share/awscli/awscli/clidriver.py", line 50, in main
   driver = create_clidriver()
 File "/usr/share/awscli/awscli/clidriver.py", line 59, in create_clidriver
   event_hooks=emitter)
 File "/usr/share/awscli/awscli/plugin.py", line 44, in load_plugins
   modules = _import_plugins(plugin_mapping)
 File "/usr/share/awscli/awscli/plugin.py", line 61, in _import_plugins
   module = __import__(path, fromlist=[module])
 File "/usr/share/awscli/awscli/handlers.py", line 39, in 
   from awscli.customizations.cloudtrail import initialize as cloudtrail_init
 File "/usr/share/awscli/awscli/customizations/cloudtrail/__init__.py",
line 14, in 
   from .validation import CloudTrailValidateLogs
 File "/usr/share/awscli/awscli/customizations/cloudtrail/validation.py",
line 25, in 
   from pyasn1.error import PyAsn1Error
ImportError: No module named 'pyasn1'

=> i.e. it misses pyasn1 too.

After installing python3-pyasn1 = 0.1.9-1, I've finally managed to get
it to run.

-- 
WBR, Mikhail Yakshin

Bug#804901: [Pkg-chromium-maint] Bug#804901: chromium: Chromium 47 breaks the GPU acceleration

[Vincent Bernat]

 ❦  7 décembre 2015 17:55 -0500, Gedalya  :

> I get the following messages:
>
> [19549:19577:1207/174928:ERROR:nss_util.cc(839)] After loading Root
> Certs, loaded==false: NSS error code: -8018
> [19596:19596:1207/174928:FATAL:sandbox_seccomp_bpf_linux.cc(203)]
> Check failed: policy->PreSandboxHook().
>
> (The latter one apparently relevant to this bug) followed by a trace.
>
> --disable-seccomp-filter-sandbox does work around the issue.
>
> Performance in my case is not as slow the previous commenter describes
> but CPU usage is a lot higher.
>
> On my desktop, it's an AMD OLAND GPU using free drivers (radeonsi),
> and I get no issue at all (also not the NSS message FWIW). Both
> machines running up-to-date stretch with chromium 47.0.2526.73-1

Got the same with an Intel GPU but I didn't notice the problem until the
bug report as my CPU is beefy enough. Intel HD Graphics 4600 in my
case.

In chrome://gpu, before the workaround:

Graphics Feature Status
Canvas: Software only, hardware acceleration unavailable
Flash: Software only, hardware acceleration unavailable
Flash Stage3D: Software only, hardware acceleration unavailable
Flash Stage3D Baseline profile: Software only, hardware acceleration unavailable
Compositing: Software only, hardware acceleration unavailable
Multiple Raster Threads: Unavailable
Rasterization: Software only, hardware acceleration unavailable
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Software only, hardware acceleration unavailable
WebGL: Unavailable

Driver Bug Workarounds
clear_uniforms_before_first_program_use
count_all_in_varyings_packing
disable_post_sub_buffers_for_onscreen_surfaces
scalarize_vec_and_mat_constructor_args
use_virtualized_gl_contexts

Problems Detected
GPU process was unable to boot: GPU access is disabled in chrome://settings.
Disabled Features: all
EXT_occlusion_query appears to be buggy with Intel GPUs on Linux
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Disable partial swaps on linux drivers: 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
MakeCurrent is slow on Linux
Applied Workarounds: use_virtualized_gl_contexts

In chrome://gpu, after the workaround:

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
WebGL: Hardware accelerated

Driver Bug Workarounds
clear_uniforms_before_first_program_use
count_all_in_varyings_packing
disable_post_sub_buffers_for_onscreen_surfaces
scalarize_vec_and_mat_constructor_args
use_virtualized_gl_contexts

Problems Detected
EXT_occlusion_query appears to be buggy with Intel GPUs on Linux
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Disable partial swaps on linux drivers: 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
MakeCurrent is slow on Linux
Applied Workarounds: use_virtualized_gl_contexts
Accelerated rasterization has been disabled, either via about:flags or command 
line.
Disabled Features: rasterization
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#807097: [Python-modules-team] Bug#807097: python-django: Undeclared removal of previously supported features causes crashes

[Brian May]

Neil Williams  writes:

>> From your stack trace it would appear that the calling application -
>> django-hijack - doesn't actually use add_to_builtins, however it uses
>> the file from django-compat that tries to import the symbol anyway.
>
> ARRRGGHHH! OK, that looks like hijack should test the import more
> carefully to identify the right support.

Think the problem is in django-compat, not django-hijack???

Somebody needs to package the latest django-compat, and this problem
should go away.
-- 
Brian May 

Bug#807378: binutils: leave ldscripts for cross package when build with -j

[YunQiang Su]

Package: src:binutils
Version: 2.25.90.20151125-2

When build binutils with -j10, ldscripts are left there.
This is due to binary-arch.% is run before install.

See the attachment.

-- 
YunQiang Su
--- a/debian/rules
+++ b/debian/rules
@@ -1300,7 +1351,7 @@ endif
 # binary-arch target  #
 ###
 
-binary.%: stamps/install.%
+binary.%: stamps/install.% install
rm -rf $(D_CROSS)/$(PF)/share/info
 
rm -rf $(D_CROSS)/DEBIAN

Bug#807377: binutils: build for N32 and MIPS r6

[YunQiang Su]

Package: src:binutils
Version: 2.25.90.20151125-2
Control: block -1 by 807340

This patch enable building n32 and {32r6,n32r6,64r6} for mips.
Please add it when dpkg patch is merged.

-- 
YunQiang Su
diff --git a/debian/control b/debian/control
index fede768..9e749ab 100644
--- a/debian/control
+++ b/debian/control
@@ -325,3 +325,107 @@ Description: GNU binary utilities, for sparc64-linux-gnu 
target
  .
  You don't need this package unless you plan to cross-compile programs
  for sparc64-linux-gnu.
+
+Package: binutils-mips64-linux-gnuabin32
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mips64-linux-gnuabin32 target
+ This package provides GNU assembler, linker and binary utilities
+ for mips64-linux-gnuabin32 target, for use in a cross-compilation environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mips64-linux-gnuabin32.
+
+Package: binutils-mips64el-linux-gnuabin32
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mips64el-linux-gnuabin32 target
+ This package provides GNU assembler, linker and binary utilities
+ for mips64el-linux-gnuabin32 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mips64el-linux-gnuabin32.
+
+Package: binutils-mipsisa32r6-linux-gnu
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa32r6-linux-gnu target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa32r6-linux-gnu target, for use in a cross-compilation environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa32r6-linux-gnu.
+
+Package: binutils-mipsisa32r6el-linux-gnu
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa32r6el-linux-gnu target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa32r6el-linux-gnu target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa32r6el-linux-gnu.
+
+Package: binutils-mipsisa64r6-linux-gnuabin32
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa64r6-linux-gnuabin32 target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa64r6-linux-gnuabin32 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa64r6-linux-gnuabin32.
+
+Package: binutils-mipsisa64r6el-linux-gnuabin32
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa64r6el-linux-gnuabin32 target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa64r6el-linux-gnuabin32 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa64r6el-linux-gnuabin32.
+
+Package: binutils-mipsisa64r6-linux-gnuabi64
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa64r6-linux-gnuabi64 target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa64r6-linux-gnuabi64 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa64r6-linux-gnuabi64.
+
+Package: binutils-mipsisa64r6el-linux-gnuabi64
+Architecture: amd64 i386 x32
+Depends: binutils (= ${binary:Version}), ${shlibs:Depends}
+Suggests: binutils-doc (= ${source:Version})
+Provides: 
+Priority: extra
+Description: GNU binary utilities, for mipsisa64r6el-linux-gnuabi64 target
+ This package provides GNU assembler, linker and binary utilities
+ for mipsisa64r6el-linux-gnuabi64 target, for use in a cross-compilation 
environment.
+ .
+ You don't need this package unless you plan to cross-compile programs
+ for mipsisa64r6el-linux-gnuabi64.
diff --git a/debian/patches/mips64-default-n64.diff 
b/debian/patches/mips64-default-n64.diff
index 7377ac1..eff6ac4 100644
--- 

Bug#807371: apt hostname resoloution failure

[Niels Thykier]

peter green:
> Package: apt
> Version: 1.1.3
> Severity: grave
> 
> When running apt in a Debian stretch armhf chroot on my odriod u2 DNS
> resoloution fails. ping is able to resolve the hostname.
> 
> [...]
> 
> The chroot is on a host system running a vendor 3.0.90 kernel, no idea
> if that is relavent. At the very least if there is a problem running on
> older kernels there should be a warning before the updated packages are
> installed.
> 
> The issue seems to be new in the 1.1 series of apt versions.
> 
> The issue definately seems to be somehow related to dns lookups. If I
> add the hostname to /etc/resolv.conf then apt seems to work.
> 
> Any thoughts on how to debug this.
> 

Is this chroot managed with/created by pbuilder/cowbuilder?

There is currently some bugs against pbuilder/cowbuilder where it fails
to update resolv.conf.  This leaves the chroot without DNS if it was
created in a different network than the one the machine is currently in.

Thanks,
~Niels

Bug#807369: apparmor: Apparmor "deny network" not working in Jessie

[Adam Jvok]

Thanks for your confirmation.

Does this imply that 'deny network' isn't going to work in any future debian
unless someone has published a patch before the kernel is built
(Or, unless this functionality goes in the kernel proper, eliminating 
the need for a patch.)?


Are there any plans to rectify this?

Without a fix it may be time to drop apparmor in favor of something else.

Thanks.

Bug#807376: ITP: ruby-rufus-scheduler -- job scheduler for Ruby

[Balasankar C]

Package: wnpp
Owner: Balasankar C 
Severity: wishlist

* Package name : ruby-rufus-scheduler
  Version : 3.1.10
  Upstream Author  : John Mettraux 
* URL  : http://github.com/jmettraux/rufus-scheduler
* License: Expat
  Programming Lang   : Ruby
  Description  : job scheduler for Ruby

-- 
Regards
Balasankar C
http://balasankarc.in

Bug#119911: ITP: alephone - marathon engine for data games

[Alexandre Detiste]

I don't think anyone else will come up with an alternative marathon engine 
anyday.

So please: one alephone source package that builds one alephone binary package
that includes three .desktop files (for a starter, the extra levels can be 
added later)
and the launcher if needed.

Keep it simple.

Please no virtual packages like for quake, better follow iortcw as an example.

GDP will not provide things like the one provided by src:quake, as there's
no way to update these after the local GDP package has been manually built.

Greets,

Alexandre

Bug#797793: samtools update seems to breaks even more tests

[Afif Elghraoui]

Hi, Andreas,

على الإثنين  7 كانون الأول 2015 ‫01:10، كتب Andreas Tille:
> 
> Hmmm, I have seen commit 7c93b9c0d42c415ef3296e6ee4a7d61b6fc34cb8 but I
> remain with failures even on amd64. :-(
> 
> 
> ...
> File "../doc/tss.rst", line 211, in tss.rst
> Failed example:
> for almnt in sortedbamfile[ window ]:
> print almnt   #doctest:+ELLIPSIS +NORMALIZE_WHITESPACE
> Exception raised:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/doctest.py", line 1315, in __run
> compileflags, 1) in test.globs
>   File "", line 1, in 
> for almnt in sortedbamfile[ window ]:
>   File 
> "/build/htseq-0.6.1p1/build/lib.linux-x86_64-2.7/HTSeq/__init__.py", line 
> 975, in __getitem__
> self.sf = pysam.AlignmentFile( self.filename, "rb" )
> AttributeError: 'module' object has no attribute 'AlignmentFile'
> **


This error appears like you're somehow using an old version of pysam
because AlignmentFile was introduced in 0.8.1. Are you sure you're not
accidentally building with a Jessie chroot (where pysam is at version
0.7.7) rather than an Unstable one?

[...]
> 
> 
> Strange that you can not reproduce this.
> 

I just made sure my working directory was clean and tried building
again. It still works for me...

regards
Afif


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

Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

[Alexandre Detiste]

Le mardi 8 décembre 2015, 12:32:33 Paul Wise a écrit :
> On Mon, Dec 7, 2015 at 8:36 PM, Alexandre Detiste wrote:
> 
> > There's one library missing: "lua-socket", which is solely used
> > for a call-home / breach of privacy anti-feature.
> >
> > I would disable it at build-time with sed.
> > (beacause lua-socket might have been pulled
> > by an other package)
> ...
> >   print "Checking for CorsixTH updates..."
> >   local update_body, status, headers = http.request(update_url)
> 
> I don't know that it is fair to call it that, it is only checking for
> updates. Obviously doing that is pointless for users of a Debian
> package, but it would be helpful for users of platforms without a sane
> update system.

I didn't wanted to sound harsh but I just didn't thought of any other name for 
this.

The lintian tags are named privacy-breach-* as well.

Bug#807246: Still doesn't work properly with local PostgreSQL

[Andrey Rahmatullin]

On Mon, Dec 07, 2015 at 09:08:40PM +0100, Paul Gevers wrote:
> On 06-12-15 17:30, Andrey Rahmatullin wrote:
> > So, I upgraded dbconfig-common and tt-rss and dpkg-reconfigure is still 
> > failing.
> 
> Just out of curiosity, where exactly does "still" refer to?
#703277 #703774

> > It also continues even after I said "Abort" (four times) and that's probably
> > how I got my DB dropped (without a backup, as it failed to produce one;
> 
> I don't see the DB dropping happening in your logging, or am I
> overseeing something?
It happened in an older session but I don't know how.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#758935: closed by Holger Levsen (closing old bug report)

[Daniel González Gasull]

Yes, the bug stop happening on the next version of torbrowser-launcher
after I reported it.

On Mon, Dec 7, 2015 at 8:15 AM, Debian Bug Tracking System
 wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the torbrowser-launcher package:
>
> #758935: torbrowser-launcher (0.1.4-1): fails to start: exit code 127
>
> It has been closed by Holger Levsen .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Holger Levsen 
>  by
> replying to this email.
>
>
> --
> 758935: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758935
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Holger Levsen 
> To: 758935-d...@bugs.debian.org
> Cc:
> Date: Mon, 7 Dec 2015 17:12:44 +0100
> Subject: closing old bug report
> Hi,
>
> I'm closing this old bug report as it was tagged unreproducible and hasnt been
> reproduced since a year, in which time there has been many new torbrowser
> releases.
>
>
> cheers,
> Holger
>
>
> -- Forwarded message --
> From: Daniel Gonzalez Gasull 
> To: Debian Bug Tracking System 
> Cc:
> Date: Fri, 22 Aug 2014 21:21:43 -0700
> Subject: torbrowser-launcher: fails to start: exit code 127
> Package: torbrowser-launcher
> Version: 0.1.3-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> torbrowser-launcher fails to start.
>
>* What led up to the situation?
>Starging torbrowser-launcher.
>
>* What was the outcome of this action?
>Window that said "Tor Browser exited abnormally.  Exit code: 127"
>
>* What outcome did you expect instead?
>I expected torbrowser to start normally.
>
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages torbrowser-launcher depends on:
> ii  gnupg1.4.18-2
> ii  python   2.7.8-1
> ii  python-gtk2  2.24.0-3+b1
> ii  python-lzma  0.5.3-2+b1
> ii  python-parsley   1.2-1
> ii  python-psutil2.1.1-1+b1
> ii  python-twisted   14.0.0-2
> ii  python-txsocksx  1.13.0.3-1
> ii  tor  0.2.4.23-1
> ii  wmctrl   1.07-7
>
> torbrowser-launcher recommends no packages.
>
> Versions of packages torbrowser-launcher suggests:
> ii  apparmor   2.8.0-5.1+b1
> ii  python-pygame  1.9.1release+dfsg-10
>
> -- no debconf information
>



-- 
Daniel González Gasull

Bug#807375: additional info

[Matthew McGehrin]

root@nas:~# tc -s class ls dev eth1
class htb 1:1 root rate 12Mbit ceil 12Mbit burst 4Kb cburst 4Kb
Sent 200619307 bytes 343473 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 5539 borrowed: 0 giants: 0
tokens: 42010 ctokens: 42010

class htb 1:10 parent 1:1 leaf 10: prio 1 rate 12Mbit ceil 12Mbit burst 
4Kb cburst 4Kb

Sent 1847501 bytes 27542 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 27542 borrowed: 0 giants: 0
tokens: 42093 ctokens: 42093

class htb 1:20 parent 1:1 leaf 20: prio 2 rate 11872Kbit ceil 12Mbit 
burst 4Kb cburst 4Kb

Sent 985635 bytes 3476 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 3355 borrowed: 2 giants: 0
tokens: 41482 ctokens: 41031

class htb 1:30 parent 1:1 leaf 30: prio 3 rate 11744Kbit ceil 12Mbit 
burst 4Kb cburst 4Kb

Sent 197786171 bytes 312455 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 304302 borrowed: 5537 giants: 0
tokens: 42933 ctokens: 42010

Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

[Paul Wise]

On Mon, Dec 7, 2015 at 8:36 PM, Alexandre Detiste wrote:

> There's one library missing: "lua-socket", which is solely used
> for a call-home / breach of privacy anti-feature.
>
> I would disable it at build-time with sed.
> (beacause lua-socket might have been pulled
> by an other package)
...
>   print "Checking for CorsixTH updates..."
>   local update_body, status, headers = http.request(update_url)

I don't know that it is fair to call it that, it is only checking for
updates. Obviously doing that is pointless for users of a Debian
package, but it would be helpful for users of platforms without a sane
update system.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#807375: iproute2: tc -s class ls dev eth1, displaying null rate 0bit 0pps backlog 0b 0p requeues 0

[Matthew McGehrin]

Package: iproute2
Version: 3.16.0-2
Severity: normal

Dear Maintainer,

When executing tc -s class ls dev eth1 to view the statistics for the Traffic 
Control, 
it's displaying 0 bits and 0pps. The actual rate seems to be active however.


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

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

Versions of packages iproute2 depends on:
ii  libc62.19-18+deb8u1
ii  libdb5.3 5.3.28-9
ii  libselinux1  2.3-2

Versions of packages iproute2 recommends:
ii  libatm1   1:2.5.1-1.5
ii  libxtables10  1.4.21-2+b1

Versions of packages iproute2 suggests:
pn  iproute2-doc  

-- no debconf information

Bug#807374: libc-bin: localedef - Add EXAMPLES section to manual page

[Jari Aalto]

Package: libc-bin
Version: 2.19-22
Severity: wishlist

Please add EXAMPLES section to manual page demonstrating usage.
Like:

  localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8

Bug#725396: Bug#807310: RFS: network-manager-ssh/0.9.4-1 [ITP] - ssh vpn for network manager

[Paul Wise]

On Mon, Dec 7, 2015 at 4:49 PM, Lennart Weller wrote:

> I am looking for a sponsor for my package "network-manager-ssh"

I don't intend to sponsor this but here is a review:

This might be a blocker, depends on if ftpmasters notice:

debian/copyright doesn't acknowledge Dan Williams although some source files do.

Here are some issues that would be nice to fix:

Why do the last two overrides in debian/rules have two tab characters
instead of one?

The upstream README file is not useful, please install README.md
instead. However README.md includes install instructions and usage
instructions for people on non-Debian distros, which aren't useful to
users of Debian binary packages so I would sed those parts out during
`debian/rules build`.

The upstream NEWS file is not useful, please don't install it.

I don't think the package descriptions should describe NetworkManager,
that is a job for the network-manager package description. Instead,
they should describe the network-manager-ssh packages.

It would be great if there were a DEP-8 test:

http://dep.debian.net/deps/dep8/
http://ci.debian.net/

I always wonder if screenshots like images/*.png should be generated
at build time so they never get out of date.

I wonder what "PCF" in the icon means, probably it would be better to
have "SSH" in there?

Upstream's po files look like they have poorly maintained or
unmaintained copyright headers.

Upstream's test suite is using an IP address belonging to the USA
Department of Defence. I would strongly suggest using a proper private
IP address according to RFC 6761.

http://tools.ietf.org/html/rfc6761

Please add some upstream metadata:

https://wiki.debian.org/UpstreamMetadata

If you contact upstream, please mention the Debian upstream guide:

https://wiki.debian.org/UpstreamGuide

Automated checks:

check-all-the-things:

$ find -type f -iname '*.sh' -exec checkbashisms {} +
could not find any possible bashisms in bash script ./test/nm-ssh-server.sh

$ codespell --quiet-level=3
./src/nm-ssh-service.c:907: arguements  ==> arguments

$ find -type f \( -iname '*.sh' -o -iname '*.bash' -o -iname '*.zsh'
\) -exec shellcheck {} +

In ./test/nm-ssh-server.sh line 27:
local external_interface=`_get_external_interface`
  ^-- SC2155: Declare and assign separately to avoid
masking return values.
 ^-- SC2006: Use $(..) instead of legacy `..`.


In ./test/nm-ssh-server.sh line 28:
iptables -t nat -I POSTROUTING -o $external_interface -j MASQUERADE
  ^-- SC2086: Double quote to
prevent globbing and word splitting.

$ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not
find or open any of the paths given.'
[properties/nm-ssh.c:1287]: (error) Possible null pointer dereference: gateway
[properties/nm-ssh.c:1289]: (error) Possible null pointer dereference: remote_ip
[properties/nm-ssh.c:1290]: (error) Possible null pointer dereference: local_ip
[properties/nm-ssh.c:1291]: (error) Possible null pointer dereference: netmask
[properties/nm-ssh.c:1316]: (error) Possible null pointer dereference:
preferred_authentication

$ find \( -name .git -o -name .svn -o -name .bzr -o -name CVS -o -name
.hg -o -name _darcs -o -name _FOSSIL_ -o -name .sgdrawer \) -prune -o
-empty -print
./ChangeLog
./NEWS
./intltool-extract.in
./intltool-update.in
./intltool-merge.in

$ flawfinder -Q -c .


$ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec
POFileChecker {} +


$ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec POFileSpell
{} +


$ find -type f \( -iname '*.po' -o -iname '*.pot' -o -iname '*.mo' -o
-iname '*.gmo' \) -exec i18nspector {} +


$ find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt
--check --check-compatibility --check-accelerators
--output-file=/dev/null {} \;   

$ grep -riE 'fixme|todo|hack|xxx' .


-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#805707: RFS: dbab/1.3.1-1 [new version update]

[Tong Sun]

Ops, you are totally right. :)

On Mon, Dec 7, 2015 at 9:03 PM, Mattia Rizzolo wrote:

> On Mon, Dec 07, 2015 at 08:51:46PM -0500, Tong Sun wrote:
> > hmm..., wait, addition of dnutils to the depends has been documented
> > in changelog, right?
> >
> > $ grep dnsutils debian/changelog
> >   - [+] add must-have Depends: dnsutils
>
> eheh, that's exactly one of the inconsistencies: the package I
> downloaded from mentors doesn't have that line. :)
>

I didn't believe it (after carefully checked my git commits), until I
downloaded and saw it myself, :-) Yeah, somehow my simplest method is
failing. :-(


> > And I need to bump up the version number a bit, as my git head has moved
> on
> > from v1.3.1. This is what I'm planning to put into my debian/changelog:
>
> and this is one of the issue I referred to when I was talking about
> keeping the debian stuff separated :)
> So, now you are "forced" to actually do another upstream release just to
> change the debian/changelog file.
> Guess this is not a problem after all, but can be annoying/frustraiting.
>

Yep, you are quite right.

I normally don't tag github releases before it has been actually uploaded
officially though. I don't know what has possessed me. :-)

... Let's just push this to the archive :)
> who knows, maybe next time the review will come sooner and this problem
> of "my head moved on" won't be a problem at all ;)


OK, will do tomorrow. thanks again.

Bug#620814: [PATCH initramfs-tools 6/6] hook-functions: Include modules for all components of a multi-disk device

[Ben Hutchings]

Control: tag -1 patch

Note, this depends on earlier patches sent to
initramfs-to...@packages.debian.org.

Ben.
---
Now that we can generically find components, we can also iterate over
them and recurse.

Closes: #620814
Signed-off-by: Ben Hutchings 
---
 hook-functions | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/hook-functions b/hook-functions
index cfd8610..482b850 100644
--- a/hook-functions
+++ b/hook-functions
@@ -231,24 +231,19 @@ block_dev_sys_walk_mod_add()
 {
    local dev_sys_path disk_sys_path component
 
-   while true; do
-   # Resolve symlink so sys_walk_mod_add can walk up the hierarchy
-   dev_sys_path="$(readlink -f "$1")"
+   # Resolve symlink so sys_walk_mod_add can walk up the hierarchy
+   dev_sys_path="$(readlink -f "$1")"
 
-   # Find whole disk from partition
-   if grep -q "^DEVTYPE=partition$" "$dev_sys_path/uevent"; then
-   disk_sys_path="$dev_sys_path/.."
-   else
-   disk_sys_path="$dev_sys_path"
-   fi
-
-   # Find first component of a layered device
-   component="$(ls -1 "$disk_sys_path/slaves" | head -n 1)"
-   if [ -z "$component" ]; then
-   break
-   fi
+   # Find whole disk from partition
+   if grep -q "^DEVTYPE=partition$" "$dev_sys_path/uevent"; then
+   disk_sys_path="$dev_sys_path/.."
+   else
+   disk_sys_path="$dev_sys_path"
+   fi
 
-   dev_sys_path="$disk_sys_path/slaves/$component"
+   # Iterate over component of a layered device
+   ls -1 "$disk_sys_path/slaves" | while read component; do
+   block_dev_sys_walk_mod_add "$disk_sys_path/slaves/$component"
    done
 
    sys_walk_mod_add ${dev_sys_path}
-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.

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

Bug#747871: [PATCH initramfs-tools 5/6] hook-functions: Rewrite block device sysfs lookup to be generic

[Ben Hutchings]

Control: tag -1 patch

Note, this depends on earlier patches sent to
initramfs-to...@packages.debian.org.

Ben.
---
There is no need to parse device names or call utilities to find
device relationships; they are all included in sysfs.

(The generic 'slaves' subdirectory has been present since 2.6.17,
DEVTYPE=partiton since 2.6.25 and /sys/dev/block since 2.6.27.)

This fixes a number of cases where we would wrongly strip a numeric
suffix from a whole-disk device name.  It also allows us to find the
components of a bcache device.

Closes: #747871, #785147, #807004, #807256
Signed-off-by: Ben Hutchings 
---
 hook-functions | 123 -
 1 file changed, 35 insertions(+), 88 deletions(-)

diff --git a/hook-functions b/hook-functions
index 95f388f..cfd8610 100644
--- a/hook-functions
+++ b/hook-functions
@@ -227,105 +227,52 @@ sys_walk_mod_add()
    done
 }
 
-block_dev_mod_add()
+block_dev_sys_walk_mod_add()
 {
-   local block minor dev_node dev_sys_path
-   dev_node="$1"
+   local dev_sys_path disk_sys_path component
 
-   # lvm or luks device
-   if [ "${dev_node#/dev/mapper/}" != "${dev_node}" ] \
-   || [ "${dev_node#/dev/dm-}" != "${dev_node}" ]; then
-   minor=$((0x$(stat --format "%T" ${dev_node}) % 256))
-   block=$(ls -1 /sys/block/dm-${minor}/slaves | head -n 1)
-   # lvm on luks or luks on lvm, possibly lvm snapshots
-   while [ "${block#dm-}" != "${block}" ]; do
-   block=$(ls -1 /sys/block/${block}/slaves | head -n 1)
-   done
-   # lvm on md or luks on md
-   if [ "${block#md}" != "${block}" ]; then
-   block=$(sed -ne 's/multipath/[/' -e 's/linear/[/' -e 
's/raid[0-9][0-9]*/[/' -e 's/\([hs]d[a-z][a-z]*\)[0-9][0-9]*/\1/g' -e 
'/^'${block}' :/s/^[^[]*\[ \([^\[]*\)\[.*$/\1/p' &2
+   dev_sys_path="$disk_sys_path/slaves/$component"
+   done
+
+   sys_walk_mod_add ${dev_sys_path}
+}
+
+block_dev_mod_add()
+{
+   local dev_node dev_num dev_sys_path
+   dev_node="$1"
+
+   # Look up device number and convert to decimal as it appears in sysfs
+   dev_num="$(stat -c %t:%T "$dev_node")"
+   dev_num="$((0x${dev_num%:*})):$((0x${dev_num#*:}))"
+
+   # Look up device in sysfs
+   dev_sys_path="/sys/dev/block/$dev_num"
+   if [ ! -d "$dev_sys_path" ]; then
+   echo "mkinitramfs: for device ${dev_node} missing 
${dev_sys_path}" >&2
    echo "mkinitramfs: workaround is MODULES=most" >&2
    echo "mkinitramfs: Error please report the bug" >&2
    exit 1
    fi
 
-   # sys walk ATA
-   dev_sys_path=$(readlink -f /sys/block/${block}/device)
-   sys_walk_mod_add ${dev_sys_path}
+   block_dev_sys_walk_mod_add "$dev_sys_path"
 }
 
 # Copy all loaded or built-in modules matching the given pattern.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.

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

Bug#807372: dar: Fails when using xz compression

[Sam Morris]

Package: dar
Version: 2.5.2-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

When creating an archive with -zxz, dar exits immediately after
printing:

# dar -v -c srv-build -s 200M -zxz --hash sha512 -R srv-build-from-obnam
Arguments read from /etc/darrc :

At least one slice of an old archive with the same name remains in the
directory /media/sam/backup. It is advised to remove all the old
archive's slices before creating an archive of same name. Can I remove
these old slices? [return = YES | Esc = NO]
Continuing...
Removing file /media/sam/backup/srv-build.1.dar
Creating low layer: Writing archive into a sar object (Segmentation and
Reassembly) for slicing...
srv-build.1.dar is about to be overwritten. [return = YES | Esc = NO]
Continuing...
Writing down the archive header...
Adding a new layer on top: Caching layer for better performances...
Adding a new layer on top: Escape layer to allow sequential reading...
Adding a new layer on top: compression...

# ls -l srv-build.*
-rw-r--r-- 1 root root67 Dec  8 03:30 srv-build.1.dar
-rw-r--r-- 1 root root 0 Dec  8 03:30 srv-build.1.dar.sha512

# dar -l srv-build
Error met while opening the last slice: Data corruption met at end of
slice, unknown flag found. Trying to open the archive using the first
slice...
Final memory cleanup...
FATAL error, aborting operation
Data corruption met at end of slice, unknown flag found

Plain old -z works fine.

- -- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable'), (540, 'testing'), (530, 
'unstable'), (520, 'experimental'), (500, 'testing-updates')
Architecture: amd64 (x86_64)

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

Versions of packages dar depends on:
ii  libassuan0 2.4.0-1
ii  libattr1   1:2.4.47-2
ii  libbz2-1.0 1.0.6-7+b3
ii  libc6  2.21-3
ii  libdar64-5000  2.5.2-1+b1
ii  libgcc11:4.9.2-10
ii  libgcrypt201.6.3-2
ii  libgpg-error0  1.17-3
ii  libgpgme11 1.5.1-6
ii  liblzo2-2  2.08-1.2
ii  libstdc++6 5.2.1-23
ii  zlib1g 1:1.2.8.dfsg-2+b1

dar recommends no packages.

Versions of packages dar suggests:
pn  dar-docs  
pn  par2  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJWZk/GAAoJENILQgJc2ie5b7oP/jQsZlmqULKFtyIWZsyvRdkp
j73kdIr7UqkYxjD6vrX1Z01x58cV8ANGFG0cOlaUHtNoXdFrVIVVUewte8SEZHTJ
80eYes0vAuWbkPyqJmXgyiMCEV+S/rfZsvq95rcCbQoFlTr6iiPqYtTjU07gwRaO
aywaGV3Luw1zmpsKBDwZKR6aTW5lqCPYCfww0Xen/s7bh3XcE3IFoHGUDFFGu5rK
YqoozdCxp+Rm9aJfgZ5yzvx3b7t+O4Y9ZOdG46Y5L114NbQPhTVIbupjxop09i+M
T5PyQJafeinTsbio/yh6K4/J15wyB7WqN8iuDf/JXMbWq6RdedhGpzWZRDAKuvH3
Vlfoetqszt3e6oE/+DmKg5i4+t4zo+4KIOFO0rv7DEparofoxDkGMzMPfbNyRM/t
IoiDKMVDDySle8K4hPakwxJZ8fxXmD2A2U3INmtqOaHpQKzEBVFKpUuCU3lzf5ga
XTtReE9xWN5GEiqQntatAzAHMk6WI9uqoCgwIJglYNkAAh9uFLjZIkEtSV2gkoqP
68caDa/fKpT4QZfNfWIYugqIktFHchK0WqYRx40NC06I8nrA3pUSvamabW4K4Bnd
2Qb2VKNRMgb1Se/8d3JNuxxszPyk/4dAlBhzYZgrRUdsqCTTFNBgwdljr48B+RGN
Fw/GgJxKXj+NkF5wCpK3
=I+ul
-END PGP SIGNATURE-

Bug#807373: apt: does not redirect stderr to stdout in calls to which

[Jonas Smedegaard]

Package: apt
Version: 1.1.4
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I noticed in commit e23ee4c (part revert, part redo 'which' replacement)
that in the command_available function the which call is documented as
including redirection of stderr to stdout whereas the places reverted to
call which does not redirect stderr.

Not sure if this is deliberate, or if not whether this may cause any
real harm or just be a tad more noisy than optimally, so setting to
severity minor for now.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWZlBwAAoJECx8MUbBoAEhv1EP/j9g9RNI5akuCY94XdMdmR85
yZk6/kbwDlQiloiS9GS9KHAGHHyhdEA9Ht0oLRiJ1HgoXnS+75MGFXk4EgueBjnz
zSnWeFOsnlk4WtEYqugI1JbKd/Dlw9bcPjPVmS8+58ZHv8FYLLlPGPy74CiaTn1R
swO95EVVSuPgjl2zzoESDR2xMcKCP7T9DyyhCf/l1mFgYjIqvDYSNsRmcnC9zKgf
1SYzt/PLv11WbqChQrqSw3i2VZ0r7chpoUmdij8rFwtKuSNbvkn1JIzD88WKwa/w
+oaojfoCjoxbweTIHjOd+JAEHmEpXbMDerNOl2tWkhiNrxkoAwzl1X56aId1C84I
PrvrZLFUR/UMhB3LZT0EN6CBsp8aR/aT554gp9WRHbROO4Q8vvq/fS09RrtPONWA
9pEdzIsGpyVYOITEIFHzVITeXW5Ao3AWkJzoeX0cCiQNwyFr5VqXvBOmXiYbBSl8
8LAyA5NOfrUQQ/vt7nhLPts39Qs7zno0c8kWKS91l7HROW36MCR4+OxkbyXDhm+j
szM2CiLXYx9VWC38tBH7Az3inxJF4nN48lqaDaH5dkj78ZFVayyqKlyGVw8Ar7Lc
EC0ycF1DxerLWmEpXVSVd3XH9mv9L6p6BljxXjxSmrpwwdF1RzfPKHRnEC46exUl
6+7UCIy9sNz7/WIXCjTC
=Q3oX
-END PGP SIGNATURE-

Bug#807280: jessie-pu: package keepassx/0.4.3+dfsg-0.1

[Reinhard Tartler]

On December 7, 2015 4:37:03 PM EST, "Adam D. Barratt" 
 wrote:
>Control: tags -1 + pending
>
>On Sun, 2015-12-06 at 19:33 -0500, Reinhard Tartler wrote:
>> I'm writing you to request approving my recent upload of
>> keepassx_0.4.3+dfsg-0.1+deb8u1. This update addresses
>> CVE-2015-8378/#791858. I'm copying Moritz, since he asked me to
>prepare
>> an upload to stable (I've already uploaded keepassx_0.4.3+dfsg-1,
>which
>> also has a fix for this included, to unstable).
>
>We generally prefer that things happen the other way around - the
>discussion, then the upload.

Noted, will do so in future.


>In any case, flagged for acceptance, thanks.

Thanks for still accepting the package!

Reinhard
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#807371: apt hostname resoloution failure

[peter green]

Package: apt
Version: 1.1.3
Severity: grave

When running apt in a Debian stretch armhf chroot on my odriod u2 DNS 
resoloution fails. ping is able to resolve the hostname.


root@odroidu2:/# apt-get update
Err:1 http://mirror.bytemark.co.uk/debian stretch InRelease
  Could not resolve 'mirror.bytemark.co.uk'
Reading package lists... Done
W: Failed to fetch 
http://mirror.bytemark.co.uk/debian/dists/stretch/InRelease  Could not 
resolve 'mirror.bytemark.co.uk'
W: Some index files failed to download. They have been ignored, or old 
ones used instead.

root@odroidu2:/# ping mirror.bytemark.co.uk
PING mirror.bytemark.co.uk (212.110.161.69) 56(84) bytes of data.
64 bytes from mirror.bytemark.co.uk (212.110.161.69): icmp_seq=1 ttl=57 
time=20.8 ms


The chroot is on a host system running a vendor 3.0.90 kernel, no idea 
if that is relavent. At the very least if there is a problem running on 
older kernels there should be a warning before the updated packages are 
installed.


The issue seems to be new in the 1.1 series of apt versions.

The issue definately seems to be somehow related to dns lookups. If I 
add the hostname to /etc/resolv.conf then apt seems to work.


Any thoughts on how to debug this.

Bug#807369: apparmor: Apparmor "deny network" not working in Jessie

[intrigeri]

Hi,

Adam Jvok wrote (08 Dec 2015 01:14:22 GMT) :
> The patches for other versions contain 'basic-networking-rules.patch'.
> I am suspicious that the lack of such a patch might be the root of the 
> problem.

Right.

Cheers,
-- 
intrigeri

Bug#807368: polymake ticket notification: #879: polymake 2.14r1 fails to build with gmp 6.1

[polymake Trac site]

#879: polymake 2.14r1 fails to build with gmp 6.1
-+-
 Reporter:  bremner  |  Owner:  joswig
 Type:  defect   | Status:  new
 Priority:  major|  Milestone:  3.0
Component:  UNKNOWN  |Version:  development
 Keywords:   |
-+-
 build fails with

 error: call of overloaded 'gcd(mpz_class&, mpz_class&)' is ambiguous

 See

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

 for a more detailed log.

 On a related note, I see libnormaliz is included in Debian now.

--
Ticket URL: 
polymake 
The polymake project

Bug#807370: libpython3.4-dev: memory leak reported by LeakSanitizer with Py_{Initialize, Finalize}

[Philipp Schrader]

Package: libpython3.4-dev
Version: 3.4.2-1
Severity: normal

Dear Maintainer,

My answers to the template questions:

   * What led up to the situation?

   I'm trying to embed Python into our product written in C and C++.
   Our build bot rejects the example from python.org because of
   memory leaks. You can find the example in section 1.1 here:
   https://docs.python.org/3.4/extending/embedding.html

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

   I compiled a file called "py_mem_leak.c" as per shell script below.

   * What was the outcome of this action?

   When you run the resulting application called "py_mem_leak", the leak
   sanitizer reports a bunch of memory leaks in libpython3.4m.so.1.0

   * What outcome did you expect instead?

   I expected the program to exit without any issues.


-- Shell script to re-create py_mem_leak.c and py_mem_leak:

#/usr/bin/env bash

set -e
set -u

cat > py_mem_leak.c <

int main() {
  Py_SetProgramName(L"test");
  Py_Initialize();
  Py_Finalize();
  return 0;
}
EOT

/usr/bin/clang-3.6 --version

/usr/bin/clang-3.6 \
  -Werror \
  -Wall \
  -Wextra \
  -pipe \
  -ggdb3 \
  -pthread \
  -U_FORTIFY_SOURCE \
  -D_FORTIFY_SOURCE=1 \
  -fstack-protector \
  -fPIE \
  -fcolor-diagnostics \
  -fno-omit-frame-pointer \
  '-fsanitize=address' \
  -g \
  -DNDEBUG \
  -ffunction-sections \
  -fdata-sections \
  -O3 \
  -std=gnu99 \
  -no-canonical-prefixes \
  -Wno-builtin-macro-redefined \
  -isystem /usr/include/python3.4m \
  '-D__DATE__="redacted"' \
  '-D__TIMESTAMP__="redacted"' \
  '-D__TIME__="redacted"' \
  -MD -MF py_mem_leak.d \
  -fPIC \
  -c \
  -o py_mem_leak.pic.o \
  py_mem_leak.c

/usr/bin/clang-3.6 \
  -o py_mem_leak \
  -pthread \
  -pipe \
  -pie \
  -Wl,-z,relro,-z,now \
  -no-canonical-prefixes \
  '-Wl,--build-id=md5' \
  '-Wl,--hash-style=gnu' \
  -Wl,--warn-execstack \
  -Wl,--detect-odr-violations \
  '-fsanitize=address' \
  '-fuse-ld=gold' \
  -Wl,--gc-sections \
  py_mem_leak.pic.o \
  /usr/lib/x86_64-linux-gnu/libpython3.4m.so \
  -lrt -lpthread -lm -lstdc++


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

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

Versions of packages libpython3.4-dev depends on:
ii  libexpat1-dev2.1.0-6+deb8u1
ii  libpython3.4 3.4.2-1
ii  libpython3.4-stdlib  3.4.2-1
ii  multiarch-support2.19-18+deb8u1

Versions of packages libpython3.4-dev recommends:
ii  libc6-dev [libc-dev]  2.19-18+deb8u1

libpython3.4-dev suggests no packages.

-- no debconf information

Bug#807331: [Pkg-samba-maint] Bug#807331: Bug#807331: samba: Fails to build from source when not being able to download docbook.xsl

[Jelmer Vernooij]

On Mon, Dec 07, 2015 at 04:07:40PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/07/2015 03:38 PM, Jelmer Vernooij wrote:
> >> That could explain the problem on sparc64 and x32, but it doesn't
> >> segfault on my amd64 machine, yet the download fails. I can run xsltproc
> >> with the URL in my sbuild chroot and it is able to download and parse
> >> the file. However, when I sbuild samba, it still fails. I can't really
> >> wrap my head around what happens here.
> > Do you have /dev/shm available in your sbuild chroot, per that bug?
> 
> Ok, this *does* fix the problem actually. I have to bind-mount dev
> into my chroot and set the permissions to 777. Vry strange that
> xsltproc does not fail when I chroot into my sbuild environment and
> call it directly, but it fails when the samba Python scripts call it.
> 
> In any case, thanks a lot for helping me to pin-point the issue. This
> is indeed a bug in xsltproc then and we can therefore close this bug
> again!
> 
> I will make the necessary modifications to all buildds in question!

You're welcome. Thank you for fixing the buildds, much appreciated!

Cheers,

Jelmer

Bug#805707: RFS: dbab/1.3.1-1 [new version update]

[Mattia Rizzolo]

On Mon, Dec 07, 2015 at 08:51:46PM -0500, Tong Sun wrote:
> hmm..., wait, addition of dnutils to the depends has been documented
> in changelog, right?
> 
> $ grep dnsutils debian/changelog
>   - [+] add must-have Depends: dnsutils

eheh, that's exactly one of the inconsistencies: the package I
downloaded from mentors doesn't have that line. :)

> So I'll be removing the line,
> 
>   - [!] closes: #774191

yes.

> And I need to bump up the version number a bit, as my git head has moved on
> from v1.3.1. This is what I'm planning to put into my debian/changelog:

and this is one of the issue I referred to when I was talking about
keeping the debian stuff separated :)
So, now you are "forced" to actually do another upstream release just to
change the debian/changelog file.
Guess this is not a problem after all, but can be annoying/frustraiting.

Anyway, for me is also fine if you just branch this release out, for
example:
$ git checkout v1.3.1
$ dch -e# modify the changelog here
$ git commit -am "modify the changelog for the debian release"
# here your HEAD is detached
$ git tag -s v1.3.1-1
$ debuild -S
$ git checkout master

but I don't really care about how you deal with the versioning of your
software or with your git repo (for example, I'd hate to do what I just
proposed you)

> Would that be looking good?
[...]

yes, it does.

> Thanks

Let's just push this to the archive :)
who knows, maybe next time the review will come sooner and this problem
of "my head moved on" won't be a problem at all ;)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#805707: RFS: dbab/1.3.1-1 [new version update]

[Tong Sun]

Oh, thank you, thank you for your kind words.

Sure, I'll fix those two you marked (and figure out the rest next).

hmm..., wait, addition of dnutils to the depends has been documented
in changelog, right?

$ grep dnsutils debian/changelog
  - [+] add must-have Depends: dnsutils

So I'll be removing the line,

  - [!] closes: #774191

And I need to bump up the version number a bit, as my git head has moved on
from v1.3.1. This is what I'm planning to put into my debian/changelog:

dbab (1.3.*2*-1) unstable; urgency=medium

  * New upstream release (1.3.*2*).
  - [!] make the pixelserv more robust
  - [!] fix dbab.service exec file name
  - [*] use dbab.md to replace dbab.html
  - [*] rename conf files to dbab.xxx (incompatible with previous
version!)
  - [!] closes: #775253 by using conf files as /etc/dnsmasq.d/dbab.xxx
  - [+] dbab.md add faq
  - [!] amend dbab.list- to reflect upstream list change
  - [*] update copyright year
  - [*] update git home
  - [+] add must-have Depends: dnsutils
  - [+] add "How to whitelist some sites" section to FAQ
  - [+] add blank-line-checking to dbab-get-list to prevent errors
  - [!] fix "dep5-copyright-license-name-not-unique"
  - [!] fix "missing-license-paragraph"

 -- Tong Sun   Fri, ...

dbab (1.2.2-2) unstable; urgency=high
...

Would that be looking good?

Thanks



On Mon, Dec 7, 2015 at 8:12 PM, Mattia Rizzolo  wrote:

> control: owner -1 !
>
> On Sun, Dec 06, 2015 at 10:17:33PM -0500, Tong Sun wrote:
> > HI Mattia, thanks for the reivew.
>
> Hi, and sorry if this sounded confused.
> These are actually my first big public review than will lead to an
> upload by me, and I figured is hard to grasp everything.
> Also I noticed I didn't specified what I (personally) require for an
> upload and what instead is just "nice to have", and what is just
> "pointless nitpick".
> I'll try to be more precise. :)
>
> > On Sun, Dec 6, 2015 at 12:32 PM, Mattia Rizzolo wrote:
> > > On Fri, Nov 20, 2015 at 11:47:21PM -0500, Tong Sun wrote:
> > > > http://mentors.debian.net/debian/pool/main/d/dbab/dbab_1.3.1-1.dsc
> > > >
> > > > Changes since last version:
> > > >
> > > >  * New upstream release (1.3.1).
> > > >   - [!] make the pixelserv more robust
> > > >   - [!] fix dbab.service exec file name
> > > >   - [!] closes: #774191
> > > >   - [*] use dbab.md to replace dbab.html
> > > >   - [*] rename conf files to dbab.xxx (incompatible with previous
> > > > version!)
> > > >   - [!] closes: #775253 by using conf files as
> > > /etc/dnsmasq.d/dbab.xxx
> > > >   - [+] dbab.md add faq
> > > >   - [!] amend dbab.list- to reflect upstream list change
> > > >   - [*] update copyright year
> > > >   - [*] update git home
> > > >   - [+] add must-have Depends: dnsutils
> > > >   - [+] add "How to whitelist some sites" section to FAQ
> > > >   - [+] add blank-line-checking to dbab-get-list to prevent
> errors
> > > >   - [!] fix "dep5-copyright-license-name-not-unique"
> > > >   - [!] fix "missing-license-paragraph"
> > >
> > > well, the chaneglog in the downloaded source package from the .dsc up
> > > there is different, it has less changes.
> > >
> >
> > It has less entries, but that doesn't means it has less changes -- the
> > one from the .dsc is more condensed, with less detailed, yet it covers
> > everything. This one just elaborate more into details.
>
> Ok, I'm ok with some changes being missing, even if I'm that kind of
> everything-must-be-the-changelog guy.
> Anyway, I want addition of dnutils to the depends to be documented.(*)
>
> > I find this way of maintaining the debian packaging of an non-native
> > > thing quite difficoult to handle.
> > >
> >
> > ..., debian/changelog is where you store debian-specific changes,
> [...]
> > You need to be more specific on what I should I do, please. Otherwise,
> I'm
> > still at lost what I should be doing. So I took a look at the debian
> > policy, and found it is quite OK to just keep one changelog file:
> [...]
> > In fact, you are the only one voicing concerns about the changelog file.
> > Since it is quite common and clearly documented in debian policy, I don't
> > need to do anything else more, right?
>
> It's ok, yes; yet this is the first package I see that is non-netive,
> share the maintainer, doesn't have upstream changelog, but the debian
> changelog document upstream changes.
>
> I don't require you do to anything, I'm just raising concerns.
> For example: you get a bug which require you to change d/rules, and for
> whatever reason you can't upload a new upstream version *now*, what do
> you do?  usually you bump the debian revision fixing it, you can do it,
> but how do you handle it on the vcs, for example?  It's totally up to
> you, yeah, I'm just lost, but I'm totally fine if you're fine.
>
> > Also, in the changelog you put two bugs, but #774191 is already closed,
> > > and cited also in the prev

Bug#485008: aptitude: 'why' doesn't seem to work

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Sam,

2013-01-09 03:01 Axel Beckert:

Sam Morris wrote:

On Sat, 2008-06-07 at 11:43 -0700, Daniel Burrows wrote:
> Could you run "aptitude-create-state-bundle aptitude-state-bundle.tar.bz2"
> and post the output somewhere that I can get to it?

Sure, I have put it at
, however it
may be too late as I removed those packages by hand. If this happens
again I will be more careful. :)


Unfortunately that file is broken (and with 224K far too small):

bzip2: Compressed file ends unexpectedly;
   perhaps it is corrupted?  *Possible* reason follows.
bzip2: Inappropriate ioctl for device
   Input file = (stdin), output file = (stdout)


Have you seen this problem more recently with other packages?

I suspected that maybe it was a problem with being virtual, but this one
works fine:

 $ aptitude why aspell-bin
 i   reportbug  Suggests   claws-mail (>= 3.8.0)
 p   claws-mail Recommends aspell-en | aspell-dictionary
 p   aspell-br  Provides   aspell-dictionary
 p   aspell-br  Suggests   aspell-bin


I then suspected that maybe the package is of priority
required/standard/etc, maybe that's why the packages depended on that
one explicitly and "why" could not find a reason.  But at least the
version that I pulled from snapshots, it's not:

$ wget -nv 
http://snapshot.debian.org/archive/debian/20080118T00Z/pool/main/g/gcj-4.1/gcj-4.1-base_4.1.2-19_amd64.deb
...
 
$ dpkg --info gcj-4.1-base_4.1.2-19_amd64.deb | grep Priority

 Priority: optional

However, when the package is installed automatically and nothing depends
on it, it fails to say that it's because of the priority:

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


So I am not sure what was going on there.

I made some tests with several other packages, esp. of these cases that
I mentioned (required like gcc-5-base, and virtual) and everything seems
to work fine now.

Maybe the underlying problem was fixed without this bug being closed.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#807369: apparmor: Apparmor "deny network" not working in Jessie

[Adam Jvok]

Subject: apparmor: Apparmor "deny network" not working in Jessie
Package: apparmor
Version: 2.9.0-3
Severity: normal

Dear Maintainer,

I would like to prevent a program being able to access the network by using
apparmor.
I've used apparmor successfully in the past for non-network stuff but
am having some trouble with this.

Here's an example of the issue

/etc/apparmor.d/usr.bin.wget

/usr/bin/wget {
# Stop apparmor complaining about some non-network stuff...
/dev/urandom r,
/lib/** mr,
/usr/lib/** mr,
/etc/** r,

# Attempt to disable network access...
deny network ,
deny network inet,
deny network inet6,
deny network raw,
deny network tcp,
deny network stream,
}

apparmor_parser -r /etc/apparmor.d/usr.bin.wget

Then test with...
/usr/bin/wget -qO- http://www.google.com

Which I would expect to fail, as I've apparently denied network access.
But it returns the page from google anyway.

Problem initially raised in forum:
http://forums.debian.net/viewtopic.php?f=10&t=126027

Looking at the source for the apparmor package in Jessie, I see it contains
a number of 'kernel_patches', but not one for the current Jessie kernel
(I have all security updates applied to date).
The patches for other versions contain 'basic-networking-rules.patch'.
I am suspicious that the lack of such a patch might be the root of the 
problem.


Thanks for looking at this.

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

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

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  initramfs-tools0.120
ii  libapparmor-perl   2.9.0-3
ii  libc6  2.19-18
ii  lsb-base   4.1+Debian13+nmu1
ii  python33.4.2-2

apparmor recommends no packages.

Versions of packages apparmor suggests:
ii  apparmor-docs2.9.0-3
ii  apparmor-profiles2.9.0-3
ii  apparmor-profiles-extra  1.4
ii  apparmor-utils   2.9.0-3

Bug#799007: bouncycastle: please package a newer version or upload 1.51-1 to unstable

[Markus Koschany]

Am 07.12.2015 um 04:40 schrieb tony mancill:
[...]
> Hi Markus,
> 
> jdeb has been uploaded.  I have libpdfbox building locally without any
> issues, but I'd like to also get the unit-tests working, but so far
> haven't had any luck.
> 
> If you'd like to take a look, I have pushed my work and bc 1.51 patch
> for libpdfbox to the git repo as branch tmancill/bc151.
> 

Hi tony,

I have enabled the unit tests on your tmancill/bc151 branch but I
couldn't find a fix so far. Some kind of ClassNotFoundException,
probably already fixed in the upcoming 2.0 version. I'd suggest to
upload as is for now and to revert my last commit.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#805707: RFS: dbab/1.3.1-1 [new version update]

[Mattia Rizzolo]

control: owner -1 !

On Sun, Dec 06, 2015 at 10:17:33PM -0500, Tong Sun wrote:
> HI Mattia, thanks for the reivew.

Hi, and sorry if this sounded confused.
These are actually my first big public review than will lead to an
upload by me, and I figured is hard to grasp everything.
Also I noticed I didn't specified what I (personally) require for an
upload and what instead is just "nice to have", and what is just
"pointless nitpick".
I'll try to be more precise. :)

> On Sun, Dec 6, 2015 at 12:32 PM, Mattia Rizzolo wrote:
> > On Fri, Nov 20, 2015 at 11:47:21PM -0500, Tong Sun wrote:
> > > http://mentors.debian.net/debian/pool/main/d/dbab/dbab_1.3.1-1.dsc
> > >
> > > Changes since last version:
> > >
> > >  * New upstream release (1.3.1).
> > >   - [!] make the pixelserv more robust
> > >   - [!] fix dbab.service exec file name
> > >   - [!] closes: #774191
> > >   - [*] use dbab.md to replace dbab.html
> > >   - [*] rename conf files to dbab.xxx (incompatible with previous
> > > version!)
> > >   - [!] closes: #775253 by using conf files as
> > /etc/dnsmasq.d/dbab.xxx
> > >   - [+] dbab.md add faq
> > >   - [!] amend dbab.list- to reflect upstream list change
> > >   - [*] update copyright year
> > >   - [*] update git home
> > >   - [+] add must-have Depends: dnsutils
> > >   - [+] add "How to whitelist some sites" section to FAQ
> > >   - [+] add blank-line-checking to dbab-get-list to prevent errors
> > >   - [!] fix "dep5-copyright-license-name-not-unique"
> > >   - [!] fix "missing-license-paragraph"
> >
> > well, the chaneglog in the downloaded source package from the .dsc up
> > there is different, it has less changes.
> >
> 
> It has less entries, but that doesn't means it has less changes -- the
> one from the .dsc is more condensed, with less detailed, yet it covers
> everything. This one just elaborate more into details.

Ok, I'm ok with some changes being missing, even if I'm that kind of
everything-must-be-the-changelog guy.
Anyway, I want addition of dnutils to the depends to be documented.(*)

> I find this way of maintaining the debian packaging of an non-native
> > thing quite difficoult to handle.
> >
> 
> ..., debian/changelog is where you store debian-specific changes,
[...]
> You need to be more specific on what I should I do, please. Otherwise, I'm
> still at lost what I should be doing. So I took a look at the debian
> policy, and found it is quite OK to just keep one changelog file:
[...]
> In fact, you are the only one voicing concerns about the changelog file.
> Since it is quite common and clearly documented in debian policy, I don't
> need to do anything else more, right?

It's ok, yes; yet this is the first package I see that is non-netive,
share the maintainer, doesn't have upstream changelog, but the debian
changelog document upstream changes.

I don't require you do to anything, I'm just raising concerns.
For example: you get a bug which require you to change d/rules, and for
whatever reason you can't upload a new upstream version *now*, what do
you do?  usually you bump the debian revision fixing it, you can do it,
but how do you handle it on the vcs, for example?  It's totally up to
you, yeah, I'm just lost, but I'm totally fine if you're fine.

> Also, in the changelog you put two bugs, but #774191 is already closed,
> > and cited also in the previous changelog entry; and that changelog entry
> > reads:
> >
> > dbab (1.2.2-2) unstable; urgency=high
> >
> >   * Targeting back to Debian Sid
> > * The reported wrong path problems was fixed in v1.2.1 (closes:
> > #774191)
> >
> > => bad.  changelog entries should contains only changes for that
> > version, not for already released ones; just to add confusion, the
> > closing message in that bug says the bug is fixed only in 1.2.2-1 :S
> >
> 
> Ok, Ok, Ok, that's a mistake, I shouldn't have listed there. I'll remove
> it. Again, please be clearer on what I should I do. Removing it is all I
> need to do, right?

yes, please remove the line 7 of the changelog, the one containing only
the closes: of an already closed bug. (*)

> > Also there is a checksum mismatch between what you released on github
> > and what's in mentors.d.n:
> > mattia@chase ~/devel/RFS/dbab % sha256sum dbab_1.3.1.orig.tar.xz
> > ~/Downloads/dbab-1.3.1.tar.gz
> > 805e4674e2e6e7622bcb1ad0a3bd9db669e8737e1dd2a22dc716346c50c64e6d
> > dbab_1.3.1.orig.tar.xz
> > 2ea7a1a2f6a664d397a926ace21e71e2745050f219bd7977921ec8b8a017db27
> > /home/mattia/Downloads/dbab-1.3.1.tar.gz
> >
> > please clarify.
> >
> 
> One is .tar.xz file, and the other is .tar.gz, so the checksum will
> definitely be different. Moreover, not only the checksum are different, the
> content are different too. I'll put the .orig.tar.xz file in the release on
> github. That will solve the problem right?

Indeed.
Is not required, but usually we try to upload to the archive the very
same tarball upstream releases (for more: for example there 

Bug#807368: polymake fails to build with gmp 6.1

[Matthias Klose]

Package: src:polymake
Version: 2.14r1-1
Severity: serious
Tags: sid stretch

Fails to build with gmp 6.1:

error: call of overloaded 'gcd(mpz_class&, mpz_class&)' is ambiguous

[...]
make[2]: Entering directory 
'/home/packages/tmp/polymake-2.14r1/build.x86_64/bundled/group/apps/matroid'
g++ -c -o projective_plane.o -fPIC -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security 
-I/home/packages/tmp/polymake-2.14r1/include/core-wrappers 
-I/home/packages/tmp/polymake-2.14r1/include/core 
-I/home/packages/tmp/polymake-2.14r1/bundled/group/include/app-wrappers 
-I/home/packages/tmp/polymake-2.14r1/bundled/group/include/apps 
-I../../../../../bundled/lrs/include/app-wrappers 
-I../../../../../bundled/lrs/include/apps 
-I../../../../../bundled/cdd/include/app-wrappers 
-I../../../../../bundled/cdd/include/apps 
-I/home/packages/tmp/polymake-2.14r1/include/app-wrappers 
-I/home/packages/tmp/polymake-2.14r1/include/apps -I/usr/include/cdd 
-I../../../../../bundled/group/external/permlib/include -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -ftemplate-depth-200 
-Wall -Wno-strict-aliasing -Wno-parentheses -fwrapv -fopenmp 
-DPOLYMAKE_APPNAME=matroid -DNDEBUG -DPOLYMAKE_DEBUG=0 -O2 -MD 
/home/packages/tmp/polymake-2.14r1/bundled/group/apps/matroid/src/projective_plane.cc
g++ -shared -L/usr/local/lib -fstack-protector -o ../../lib/matroid.so 
projective_plane.o -Wl,-z,relro -Wl,-z,relro -fopenmp  -lmpfr -lgmp -lpthread 
make[2]: Leaving directory 
'/home/packages/tmp/polymake-2.14r1/build.x86_64/bundled/group/apps/matroid'
make[2]: Entering directory 
'/home/packages/tmp/polymake-2.14r1/build.x86_64/bundled/libnormaliz/apps/polytope'
/usr/bin/perl /home/packages/tmp/polymake-2.14r1/support/guarded_compiler.pl 
g++ -c -o normaliz.o -fPIC -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security 
-I/home/packages/tmp/polymake-2.14r1/include/core-wrappers 
-I/home/packages/tmp/polymake-2.14r1/include/core 
-I/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/include/app-wrappers 
-I/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/include/apps 
-I/home/packages/tmp/polymake-2.14r1/include/app-wrappers 
-I/home/packages/tmp/polymake-2.14r1/include/apps -fopenmp -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -ftemplate-depth-200 
-Wall -Wno-strict-aliasing -Wno-parentheses -fwrapv -fopenmp 
-DPOLYMAKE_APPNAME=polytope -DNDEBUG -DPOLYMAKE_DEBUG=0 -O2 -MD  
-I/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/external/libnormaliz  
-I/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/apps/polytope 
-I/home/packages/tmp/polymake-2.14r1/apps/polytope -include src/normaliz.cc 
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/apps/polytope/src/perl/wrap-normaliz.cc
In file included from 
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/external/libnormaliz/libnormaliz-all.cpp:37:0,
 from 
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/apps/polytope/src/normaliz.cc:39,
 from :0:
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/external/libnormaliz/HilbertSeries.cpp:
 In member function 'void 
libnormaliz::HilbertSeries::computeHilbertQuasiPolynomial() const':
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/external/libnormaliz/HilbertSeries.cpp:358:26:
 error: call of overloaded 'gcd(mpz_class&, mpz_class&)' is ambiguous
 g = gcd(g,quasi_denom);
  ^
In file included from 
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/external/libnormaliz/libnormaliz-all.cpp:25:0,
 from 
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/apps/polytope/src/normaliz.cc:39,
 from :0:
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/external/libnormaliz/integer.cpp:77:22:
 note: candidate: Integer libnormaliz::gcd(const Integer&, const Integer&) 
[with Integer = __gmp_expr<__mpz_struct [1], __mpz_struct [1]>]
 template<> mpz_class gcd(const mpz_class& a, const mpz_class& b) {
  ^
In file included from 
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/apps/polytope/src/normaliz.cc:18:0,
 from :0:
/usr/include/gmpxx.h:3083:1: note: candidate: __gmp_expr::value_type, __gmp_binary_expr<__gmp_expr, 
__gmp_expr, __gmp_gcd_function> > gcd(const __gmp_expr&, const 
__gmp_expr&) [with T = __mpz_struct [1]; U = __mpz_struct [1]; V = 
__mpz_struct [1]; W = __mpz_struct [1]; typename __gmp_resolve_expr::value_type = __mpz_struct [1]]
 __GMP_DEFINE_BINARY_FUNCTION(gcd, __gmp_gcd_function)
 ^
In file included from 
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/external/libnormaliz/libnormaliz-all.cpp:26:0,
 from 
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/apps/polytope/src/normaliz.cc:39,
 from :0:
/home/packages/tmp/polymake-2.14r1/bundled/libnormaliz/external/libnormaliz/vector_operations.cpp:
 In instantiation of 'Integer libnormaliz::v_gcd(const s

Bug#119911: ITP: alephone - marathon engine for data games

[PICCORO McKAY Lenz]

ok lest take in consideration u'r notes:

2015-12-07 17:24 GMT-04:30, Alexandre Detiste :
> For new games it is probably better to use game-data-packager to ship
> only
> the non-distributable files, and ship DFSG files (such as icons
> and .desktop files) somewhere else.
its the way proposed also in the second suggestion:
>
> One way is to have the engine package contain the wrapper scripts,
> .desktop files etc. (e.g. src:openjk, src:iortcw). This is the simplest
> thing if the engine is unlikely to be used for other games and
> alternative
> engine versions are unlikely to be packaged.
currently alephone only works for marathon related games, so there's
no other game derived! but the secon approach also can be applied due
the wrapper script can be put in those kind of package:
>
> Another approach is to have a package for the engine (like
> src:ioquake3)
> and a package for the user-visible game (like src:quake, containing
> wrapper scripts, .desktop files etc.). This is more flexible if the
> engine
> can be used for other user-visible games (e.g. OpenArena, Nexuiz
> Classic)
> or there could reasonably be multiple packaged engines (e.g.
> Quakespasm,
> Darkplaces).
>
> If you provide a .desktop file for each episode,
> then each can call the engine directly without needing a wrapper script.
>
i can provide it, inclusivelly i already doit! but firts we must
decided how we made the scenarios packages! or what will be included
in the engine package, do u take a review on the files i provided? or
something!?

-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#784500: Qt GUI of Navit can be removed

[Sebastian Leske]

Hi,

the Qt graphics plugin in Navit is currently unmaintained, so it's probably
best to drop it from the Debian package - it's barely usable at the
moment.

Once it starts being maintained, it will probably be migrated to Qt 5.

Greetings

Sebastian Leske

P.S. You forwarded this bug to the GitHub issue tracker, which was only
enabled temporarily by mistake. Navit bugs should be reported to
http://trac.navit-project.org/ . Thanks!

Bug#601135: Cannot be fixed without an example file

[Sebastian Leske]

Hi,

thanks for bringing up this bug report.

Unfortunately, I think as it stands this bug will need to be closed as
unreproducible.
Without having the file the bug reporter used, it's next to impossible
to tell what the problem was - in particular because there are different
versions / variations of the Garmin file format.

To test Navit's Garmin map driver, I just randomly grabbed a Garmin map
file off the Internet - I used the file from
http://www.miscjunk.org/mj/mp_mnohv.html , specifically
http://www.miscjunk.org/mj/downloads/mnohv_install.exe .
Running it (e.g. with wine) produces a file 8801.img , which can be
loaded as a Navit map (map entry with type="garmin", enabled="yes",
data="/path/to/8801.img").

Then moving to coordinates 47.4874N 92.4679W shows the streets of
Gilbert, Minnesota.

So the Garmin map driver (still) works in principle. Thus without a
reproducible test case (including a map file), I propose to close this
bug.

Greetings

Sebastian Leske

Bug#806965: oclgrind: FTBFS on ppc64el -- conflict with altivec keyword bool

[J Price]

reopen 806965
thanks

On 7 December 2015 at 11:08, Fernando Seiti Furusato
 wrote:
>
> > I think -mno-altivec is rather a quick workaround and __vector the
> > proper fix.
>
> Yes, I agree with Andreas. Mine was just a less invasive workaround,
> because I preferred not to mess with the code.

OK, the ppc64el build is still failing with the __vector patch. It's
not clear to me where the errors are originating.

>From the GCC page on AltiVec [1]:
> Macros vector, pixel, and bool are defined in  and can be 
> undefined.

Perhaps we need to #undef these macros in cl.h after  is
included, to prevent them from causing problems in the source files
that include cl.h?

[1] 
https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/PowerPC-AltiVec-Built_002din-Functions.html

Bug#348679: aptitude: doesn't do downgrade for packages pinned high

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Marc,

2006-01-18 11:52 Marc Haber:

Package: aptitude
Version: 0.4.1-1experimental1
Severity: normal

Hi,

I have pinned unstable to 2000 on my box:

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 2000

This is obviously processed correctly:

$ apt-cache policy apt
apt:
 Installed: 0.6.43.2exp1
 Candidate: 0.6.43.1
 Version table:
*** 0.6.43.2exp1 0
   -10 http://debian.debian.zugschlus.de experimental/main Packages
   100 /var/lib/dpkg/status
0.6.43.1 0
  2000 http://debian.debian.zugschlus.de sid/main Packages
0.6.43exp2 0
   500 http://zg.debian.zugschlus.de zg/sid/main Packages
0.5.28.6 0
   500 http://debian.debian.zugschlus.de sarge/main Packages
$

Also, apt-get dist-upgrade plans to do some downgrade:

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following NEW packages will be installed:
 libslang1
The following packages will be DOWNGRADED:
 apt apt-utils aptitude exim4 exim4-base exim4-config exim4-daemon-light
 eximon4 jed jed-common libapt-pkg-perl libnasl2 libnessus2 python-apt
 python2.3-apt
0 upgraded, 1 newly installed, 15 downgraded, 0 to remove and 0 not upgraded.
Need to get 7200kB of archives.
After unpacking 512kB of additional disk space will be used.
Do you want to continue [Y/n]? n
Abort.
$

But aptitude doesn't.

$ sudo aptitude dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
$

Additionally, "U" in interactive aptitude doesn't do anything as well.


Thanks for the report.

I commited a fix to VCS and all of the modalities of upgrades now work
with this.  Will be present in the next release, so marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#344700: ignores /etc/apt/preferences

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2005-12-24 22:21 ms...@freezone.co.uk:

Package: aptitude
Version: 0.4.1-1

These lines in /etc/apt/preferences downgrade gcc-4.0 using apt-get, but
not aptitude -


Package: gcc-4.0
Pin: release o=Debian
Pin-Priority: 1001


fis:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be DOWNGRADED:
 gcc-4.0
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not
upgraded.
Need to get 27.8kB of archives.
After unpacking 69.6kB disk space will be freed.
Do you want to continue [Y/n]?


fis:~# aptitude -DR dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
Building tag database... Done
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
fis:~#


Many thanks for maintaining aptitude - it's a fine tool!

Jack




2006-03-16 22:55 ms...@freezone.co.uk:

I found aptitude does respect these lines in /etc/apt/preferences -


Package: *
Pin: release a=experimental
Pin-Priority: 100


However downgrading remains impossible



Thanks for this report.

The fix was commited for VCS and will be present in the next release,
marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#807323: gparted needs policykit-1 but its neither in depends or recommends

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/07/2015 11:57 AM, shirish शिरीष wrote:
> Yup, have udisks2 installed.

Just to confirm, can you run /usr/lib/udisks2/udisks2-inhibit and
verify that you get that error?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWZiC8AAoJEBB5UWFcu6UWdjoH/R9bl1ScxaDvNw0dAw5hYTjQ
xVOJ/zbk9DiC11H4xrPC2sLCKlomQnP9Vd7OFbVgX7tOZs0ANly270/VuB1nzqlv
AtfkOy1NEyoAuUXvLPh8CR/kV4a81qFej2wuh+PuyJuUyvBy4/pcSLkcWBvYCkQD
cQZzzXFtxE44u7M3tWr3odYWcg0S7vduUVg12GmnB6yqZYTIVFmjv5FUo/S8IXFW
Sw8WLE3Vzl/m8lLKjeh9Xk3whdcAoLWVpTUC5zbC5pCUw2/qGBUrEwR6hbYWDbim
9FSAnBHydoE8L+cDEh8mOl1IHLoqnWp7JdF0JWWFSZ58qFfAe6iGxGFU12x0xUQ=
=t2mk
-END PGP SIGNATURE-

Bug#807365: cowbuilder: network broken in cowbuilder - cannot resolve any hostname

[Norbert Preining]

> fix coming..

Thanks a lot!

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#807367: [PATCH] edspsystem.cc: include for mkdtemp

[Fredrik Fornwall]

Package: apt
Version: 1.1.4
Severity: normal
Tags: patch

Include  to ensure that mkdtemp(3) is defined to improve
general portability and fix a specific build failure on Android.

---
 apt-pkg/edsp/edspsystem.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/apt-pkg/edsp/edspsystem.cc b/apt-pkg/edsp/edspsystem.cc
index 95abc15..0d96786 100644
--- a/apt-pkg/edsp/edspsystem.cc
+++ b/apt-pkg/edsp/edspsystem.cc
@@ -20,6 +20,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
-- 
2.6.3

Bug#597742: Typo in changelog

[Gioele Barabucci]

Control: tags -1 + patch
Control: retitle -1 dash: Typo in changelog closes the wrong bug

A tiny patch to fix the typo and close the correct bug.

>From 934f67c7ad614471dbb6b5811667aa252fb3e44f Mon Sep 17 00:00:00 2001
From: Gioele Barabucci 
Date: Mon, 7 Dec 2015 23:34:39 +
Subject: [PATCH] Fix typo in changelog closing the wrong bug

diff --git a/debian/changelog b/debian/changelog
index eac6a01..521dc70 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -185,7 +185,7 @@ dash (0.5.5.1-7.1) unstable; urgency=low
 dash (0.5.5.1-7) unstable; urgency=low
 
   [ Raphael Geissert ]
-  * Re-add code to allow taking over bash's diversion (Closes: #82554).
+  * Re-add code to allow taking over bash's diversion (Closes: #582554).
 
   [ Gerrit Pape ]
   * debian/dash.README.source: new; document how to use the Debian

-- 
Gioele Barabucci 

Bug#807366: ghc: disable PIE on Ubuntu/s390x

[Colin Watson]

Package: ghc
Version: 7.10.3-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch xenial

The newly-bootstrapped Ubuntu s390x architecture has its toolchain
configured to use PIE by default (I presume by customer request, though
I don't know the details).  Binaries built by GHC segfault immediately
if PIE is in use.  I think it would make sense to just disable PIE on
s390x; it's not enabled by default on Debian s390x, but -fno-PIE/-no-pie
should be harmless.

Disabling this both during the GHC build itself and for things that the
resulting /usr/bin/ghc compiles requires a couple of different pieces.
Here's a tested patch (which could be refactored later if more
architectures have this problem in future):

diff --git a/p/ghc/debian/rules b/p/ghc/debian/rules
index b285537..ca8d8f3 100755
--- a/p/ghc/debian/rules
+++ b/p/ghc/debian/rules
@@ -34,6 +34,12 @@ ProjectVersion=$(shell cat VERSION)
 
 GHC=$(firstword $(shell bash -c "type -p ghc"))
 EXTRA_CONFIGURE_FLAGS=--with-ghc="$(GHC)"
+ifeq (s390x,$(DEB_HOST_ARCH))
+  EXTRA_CONFIGURE_FLAGS += \
+   CONF_CC_OPTS_STAGE2=-fno-PIE \
+   CONF_GCC_LINKER_OPTS_STAGE2=-no-pie \
+   CONF_LD_LINKER_OPTS_STAGE2=-no-pie
+endif
 BUILD_HADDOCK_DOCS=YES
 DEB_HOOGLE_TXT_DIR = /usr/lib/ghc-doc/hoogle/
 
@@ -51,6 +57,10 @@ endif
 ifeq (armhf,$(DEB_HOST_ARCH))
echo "SRC_HC_OPTS += -D__ARM_PCS_VFP" >> mk/build.mk
 endif
+ifeq (s390x,$(DEB_HOST_ARCH))
+   echo "SRC_CC_OPTS += -fno-PIE" >> mk/build.mk
+   echo "SRC_LD_OPTS += -no-pie" >> mk/build.mk
+endif
 ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
 #  echo "GhcStage1HcOpts += -DDEBUG" >> mk/build.mk
 #  echo "GhcStage2HcOpts += -DDEBUG" >> mk/build.mk

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]

Bug#807041: logind: laptop unexpectedly auto-suspends after some time of inactivity

[George B.]

On 04/12/15 14:39, Michael Biebl wrote:


Can you attach the output of (as root)
journalctl -u systemd-logind

and mark the time when the auto-suspend happens.


```
-- Logs begin at Mon 2015-12-07 14:25:13 GMT, end at Mon 2015-12-07 23:26:59 
GMT. --
Dec 07 14:25:15 deli systemd[1]: Starting Login Service...
Dec 07 14:25:15 deli systemd-logind[920]: New seat seat0.
Dec 07 14:25:15 deli systemd[1]: Started Login Service.
Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on 
/dev/input/event9 (Power Button)
Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on 
/dev/input/event10 (Video Bus)
Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on 
/dev/input/event7 (Power Button)
Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on 
/dev/input/event6 (Lid Switch)
Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on 
/dev/input/event8 (Sleep Button)
Dec 07 14:25:15 deli systemd-logind[920]: Watching system buttons on 
/dev/input/event14 (Dell WMI hotkeys)
Dec 07 14:25:26 deli systemd-logind[920]: New session 1 of user borisov.
Dec 07 19:37:36 deli systemd-logind[920]: Suspending...
Dec 07 23:26:28 deli systemd-logind[920]: Operation 'sleep' finished.
```

The "Suspending" message would be around the time that the suspend happened 
(~15 minutes after I left it alone).


Best regards,

George

Bug#807001: [Pkg-xfce-devel] Bug#807001: lightdm fails to register user-sessions

[Daniel Reichelt]

On 12/07/2015 01:30 PM, Yves-Alexis Perez wrote:
> On sam., 2015-12-05 at 17:59 +0100, Daniel Reichelt wrote:
>> Up until now I thought, lightdm failed to correctly register a
>> user-session, when really it failed to register one at all...
> 
> It might very well be because it reuses the ssh session or something. I think
> it'd help to remove this from the equation.
> 
> Regards,
> 

Right, it does re-use the session from the shell `service lightdm
restart` was invoked from. But there's no difference if that shell comes
from a ssh- or from a local login.

Here's `loginctl show-session` after I did the service restart from tty1:

8<
Id=3
Name=root
Timestamp=Mon 2015-12-07 22:22:43 CET
TimestampMonotonic=77192700
VTNr=1
TTY=/dev/tty1
Remote=no
Service=login
Scope=session-3.scope
Leader=6813
Audit=3
Type=tty
Class=user
Active=no
State=online
IdleHint=no
IdleSinceHint=1449523377884000
IdleSinceHintMonotonic=91836528
8<




And here goes another experiment: To circumvent that whole systemd
session hullabaloo, I added /bin/bash to /etc/inittab like this:
8<
8:S2:respawn:/bin/bash -il >/dev/tty8 2>&1 

Bug#799890: policykit-1: Shutdown/reboot requires authentication

[Gedalya]

Between November 29 and 30 I got policykit-1 0.105-14, systemd 228-2, 
lightdm 1.16.6-1.

After a full reboot, the issue is gone. Just logging out didn't help.
I only realized now since I hadn't had a chance to reboot any machine in 
the mean time.

My guess is the fix is in one of these 3 packages, no concrete evidence.

Bug#807365: cowbuilder: network broken in cowbuilder - cannot resolve any hostname

[Mattia Rizzolo]

control: reassign -1 pbuilder 0.221
control: forcemerge 806386 -1
control: tag 806386 + pending

On Tue, Dec 08, 2015 at 08:05:55AM +0900, Norbert Preining wrote:
> probably since one of the updates of pbuilder, cowbuilder stopped 
> being able to resolve host names:

yeah, my fault, fix coming..
-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#807148: glx-diversions: ffmpeg looks for libGL.so.1 while glx-diversions offers only libGL.so

[Xinyue Lu]

I spend some time investigating this issues.

It turns out glx-alternative-{...} is not installed. That's why when I
remove glx-diversions the file went back.

Reproduce by -

$ sudo aptitude install glx-diversions --without-recommends

$ LANG=C ll /usr/lib/x86_64-linux-gnu/libGL.*
zsh: no matches found: /usr/lib/x86_64-linux-gnu/libGL.*

$ sudo aptitude remove glx-diversions

$ LANG=C ll /usr/lib/x86_64-linux-gnu/libGL.*
lrwxrwxrwx 1 root root   14 Nov 27 04:55
/usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.2.0
-rw-r--r-- 1 root root 605K Nov 27 04:56
/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0

--

Thanks.



2015-12-07 15:50 GMT-05:00 Andreas Beckmann :
> Control: tag -1 moreinfo unreproducible
>
> On 2015-12-07 20:07, Luca Boccassi wrote:
>> On Sat, 2015-12-05 at 22:17 -0500, Xinyue Lu wrote:
>>> I've noticed that my ffmpeg doesn't work and reporting missing shared
>>> library libGL.so.1.
>
>> I had a look but cannot reproduce this on either of my systems.
>> libGL.so.1 is correctly installed by update-alternatives when
>> mesa-diverted is configured.
>
> I cannot reproduce this either.
>
> I could only think of one case: glx-diversions is installed but not any
> of the glx-alternative-{mesa,nvidia,fglrx} packages. But that must have
> been a manual install since anything depending on glx-diversions (some
> bits of a non-free graphics driver) will depend on (at least) one of
> glx-alternative-*, too.
> And glx-diversions also Recommends: glx-alternative-mesa, so if you end
> up without any alternatives, this must have been done conciously.
>
>
> Andreas

Bug#807249: needs versioned build dependency on python3-setuptools-scm

[Gianfranco Costamagna]

Hi again :)



>I use the package, and I do even dare doing my own backports, finding
>issues, and reporting them.


thanks for this :)
>I couldn't do too much to help. See, even my bug reports are wrong ;-)


not at all
>You're right.


not completely
>Yes, this issue might have been caused by a local package of mine
>built and used before borgbackup required a later version. I apologize
>for my lack of python knowledge.


the bug is still true, maybe not for Debian, but I can think about a debian 
derivative that
got a freeze when setuptools-scm was at an unsuitable version, and gets a 
backport of the tool.
(or maybe people carefully apt-pinning stuff from testing, and updating 
borgbackup without updating setuptool-scm.

So even if you found the bug in the wrong way, the bug still persists and you 
are right (even if I don't think
many people will hit such use-case, I checked and at least ubuntu and ubuntu 
based shouldn't unsuitable versions)

cheers!

G.

Bug#804901: chromium: Chromium 47 breaks the GPU acceleration

[Gedalya]

Tried another machine. Reproduced with an nvidia card, using nouveau

Bug#807365: cowbuilder: network broken in cowbuilder - cannot resolve any hostname

[Norbert Preining]

Package: cowbuilder
Version: 0.75
Severity: grave
Justification: renders package unusable

Dear all,

probably since one of the updates of pbuilder, cowbuilder stopped 
being able to resolve host names:
# cowbuilder --login --save-after-login
 -> Copying COW directory
  forking: rm -rf /var/cache/pbuilder/build/cow.11509 
  forking: cp -al /var/cache/pbuilder/base.cow 
/var/cache/pbuilder/build/cow.11509 
I: removed stale ilistfile /var/cache/pbuilder/build/cow.11509/.ilist
 -> Invoking pbuilder
  forking: pbuilder login --buildplace /var/cache/pbuilder/build/cow.11509 
--no-targz --internal-chrootexec chroot /var/cache/pbuilder/build/cow.11509 
cow-shell 
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: copying local configuration
I: mounting /proc filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: entering the shell


root@wienerschnitzel:/# apt-get update
Err http://ftp2.jp.debian.org sid InRelease
  
Err http://ftp2.jp.debian.org sid Release.gpg
  Could not resolve 'ftp2.jp.debian.org'
Reading package lists... Done
W: Failed to fetch http://ftp2.jp.debian.org/debian/dists/sid/InRelease  

W: Failed to fetch http://ftp2.jp.debian.org/debian/dists/sid/Release.gpg  
Could not resolve 'ftp2.jp.debian.org'

W: Some index files failed to download. They have been ignored, or old ones 
used instead.



Same happens with any other host. Network seems to be unusable.

Thanks

Norbert


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

Kernel: Linux 4.4.0-rc3+ (SMP w/4 CPU cores; PREEMPT)
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 cowbuilder depends on:
ii  cowdancer  0.75
ii  libc6  2.21-3
ii  pbuilder   0.221.1

cowbuilder recommends no packages.

cowbuilder suggests no packages.

-- no debconf information

Bug#804901: chromium: Chromium 47 breaks the GPU acceleration

[Gedalya]

Thinkpad T430, Ivy Bridge i5-3230M.

I get the following messages:

[19549:19577:1207/174928:ERROR:nss_util.cc(839)] After loading Root 
Certs, loaded==false: NSS error code: -8018
[19596:19596:1207/174928:FATAL:sandbox_seccomp_bpf_linux.cc(203)] Check 
failed: policy->PreSandboxHook().


(The latter one apparently relevant to this bug) followed by a trace.

--disable-seccomp-filter-sandbox does work around the issue.

Performance in my case is not as slow the previous commenter describes 
but CPU usage is a lot higher.


On my desktop, it's an AMD OLAND GPU using free drivers (radeonsi), and 
I get no issue at all (also not the NSS message FWIW). Both machines 
running up-to-date stretch with chromium 47.0.2526.73-1

Bug#807019: tracking bin-num - broken unison due to binnmu upload

[Norbert Preining]

Dear Stéphane,

> But I now understand the problem: unison2.40.102 uses Obj.magic (i.e. an
> unsafe coercion) to cast a format string into a string. The previous
> unison version was compiled with OCaml 4.01.0, where format strings were
> indeed strings. The new version was compiled with OCaml 4.02.3, where it
> is no longer the case. unison2.32.52 should suffer from the same problem.

Uhh, thanks for tracking this down.

> The change done in unison 2.48 to overcome this looks pretty big... I'm
> not sure I'll be able/willing to provide a unison2.40.102 any more.

That would be a pity.

> Moreover, this package was created to provide compatibility with
> previous Debian releases, but another change in OCaml 4.02 makes it

Unfortunately I am even running old-stable, but till now had no
problems using 2.40 with the unison from old-stable. I will need
to look into that how I can keep that running.

Thanks a lot and all the best

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#807364: RFP: supercollider-sc3-plugins -- Community collection of UGen plugins for SuperCollider

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist

* Package name: supercollider-sc3-plugins
  Version : 3.7.0-alpha1
  Upstream Author : SuperCollider Development Team 
* URL : https://github.com/supercollider/sc3-plugins
* License : GPL v2+
  Programming Lang: C++
  Description : Community collection of UGen plugins for SuperCollider

Extension plugins for the SuperCollider3 audio synthesis server.  These
third-party plugins provide additional synthesis, analysis, and other
capabilities for the sound server.

This package is needed by sonic-pi (WNPP request #796550).

A draft package is available from
http://ppa.launchpad.net/sonic-pi/ppa/ubuntu/pool/main/s/supercollider-sc3-plugins/
 >

-- 
Happy hacking
Petter Reinholdtsen

Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)

[Andreas Beckmann]

Dear libc maintainers,

we recently got a bug report regarding the TSX-NI / lock elision bug in
combination with the non-free nvidia driver (#807244). Since that is
supposed to be fixed with the libc in experimental (and now sid as
well), perhaps you could take a look why this still happens.
Several forum posts denote that "compiling glibc without
--enable-lock-elision" works around that issue.

A few ideas from my side, but since I don't have the hardware to test, I
cannot check anything:
* that specific CPU needs to be blacklisted / is incorrectly whitelisted
* nvidia utilizes a code path in libc that is not covered by the current
patch (and that code path is not used by any other application)
* nvidia does call something it shouldn't call directly ... thus
circumenting the runtime-disabling of the specific routines in libc6
* nvidia code does issue the problematic instructions itself (but the
backtrace points to libc, so this sounds unlikely)

Is there some way to check at runtime how lock elision is handled by
libc (on a concrete system)?

Andreas

On 2015-12-06 17:53, Jelle Haandrikman wrote:
> On a system with an Nvidia GTX 970, Intel Skylake i5-6600k running driver
> 352.63-1 (experimental) several programs crash due to TSX-NI / elision unlock.
> This affects sddm, unlocking kscreen, vlc and deleting files using dolphin.
> 
> Other people also have found this issue.
> http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/nvidia-linux/825702-nvidia-s-latest-binary-driver-is-causing-problems-for-some-skylake-linux-users
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574 #800574
> https://devtalk.nvidia.com/default/topic/893325/newest-and-beta-linux-driver-causing-segmentation-fault-core-dumped-on-all-skylake-platforms/
> 
> Bug #800574 suggest to disable elisian-unlock in glibc. Which is already
> incorporated in experimental. This does not alleviate the issue. See the 
> "steps
> to reproduce" below. The same bug suggests that the nvidia driver still has
> problems. I also run intel-microcode update, but that doesn't solve anything.

> Step to reproduce: gdb vlc
> output:
> (gdb) run
> Starting program: /usr/bin/vlc
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision 
> 2.2.1-0-ga425c42)
> 
> Program received signal SIGSEGV, Segmentation fault.
> __lll_unlock_elision (lock=0x726d0d08, private=0)
> at ../sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
> 29  ../sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or
> directory.
> (gdb) bt
> #0  __lll_unlock_elision (lock=0x726d0d08, private=0)
> at ../sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
> #1  0x7247f26c in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
> #2  0x7240fa22 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
> #3  0x7fffd960 in ?? ()
> #4  0x72493ea1 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
> #5  0x7fffd960 in ?? ()
> #6  0x77def59e in _dl_close_worker (map=,
> force=)
> at dl-close.c:291
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> /usr/lib/x86_64-linux-gnu/libEGL.so.1 -> /usr/lib/x86_64-linux-
> gnu/nvidia/libEGL.so.1
> 
> "dmesg|grep pthread" result:
> breetai@mainbak:~$ dmesg |grep pthread
> [73330.105569] traps: vlc[16815] general protection ip:7f47ac388950
> sp:7ffe3908ad98 error:0 in libpthread-2.22.so[7f47ac376000+18000]
> [78860.282876] traps: dolphin[18294] general protection ip:7fc3b0c1b950
> sp:7ffd0a0828d8 error:0 in libpthread-2.22.so[7fc3b0c09000+18000]
> [90812.515421] traps: krunner[20723] general protection ip:7f930fa19950
> sp:7ffc9b5cd988 error:0 in libpthread-2.22.so[7f930fa07000+18000]
> [90826.164341] traps: akonadi_migrati[21161] general protection 
> ip:7f33b7e39950
> sp:7fff9d61bef8 error:0 in libpthread-2.22.so[7f33b7e27000+18000]
> [92621.782318] traps: vlc[21962] general protection ip:7f4241467950
> sp:7ffd8fa98f68 error:0 in libpthread-2.22.so[7f4241455000+18000]
> breetai@mainbak:~$
> 
> 
> installed packages:
> System runs testing.
> 
> libc6:amd64 2.22-0experimental0 from experimental
> nvidia-driver   352.63-1from experimental
> intel-microcode 3.20151106.1from testing
> vlc 2.2.1-5+b1  from testing

Bug#806955: icedove: fails to start with "Failed to read the config file"

[Meik Hellmund]

On Sat, 5 Dec 2015 10:50:03 +0100
Carsten Schoenert  wrote:


> 
> You trying to keep specific Icedove settings modified by a extra file in
> 
>   /etc/icedove/pref/
> 
> with a locking preference.
> 
> http://kb.mozillazine.org/Locking_preferences
> 
> I'm not sure if that is what you are really wanted to do.

No, not really. All the preferences I use are defaultPrefs, not lockPrefs.

But as far as I understand it, there is a difference between a .js and a .cfg 
file.
.cfg files allow special commands to get config values from, e.g., an LDAP 
database
(called the  "Pref API" according to
  http://web.mit.edu/~thunderbird/www/maintainers/autoconfig.html )

This seems to be quite poorly documented. 
All I know about it is from web sites like 
  http://web.mit.edu/~thunderbird/www/maintainers/autoconfig.html
  
https://developer.mozilla.org/en-US/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig
  https://github.com/interlegis/puppet-thunderbird/tree/master/templates
But it is quite useful in a centrally administrated environment.
You can get our mathmail.cfg file for the next few days from
   http://www.math.uni-leipzig.de/~hellmund/mathmail.cfg
It takes the userid from the environment, makes a LDAP lookup
of the full name and the mail address for this userid and configures 
the mail  account. It works fine, new users on our Institute's network of
debian machines only have to enter their password at the first start of icedove 
and 
everything works. 



> And yes, exact this handling of the a additional default configuration
> file has changed somewhere on the way to version 38.
> 
> With strace you will see that nevertheless you want to adjust a specific
> path to the global configuration file Icedove will always search the
> file in the main installation folder.
> 
> > ...
> > pref('general.config.filename', 'defaults/syspref/mathmail.cfg');
> > ...

Exactly. So the question is: is this use case worth an additional Debian patch
so that the path is replaced/amended by /etc/icedove/pref/ ?

I did an "apt-get source icedove" and poked into it, but this is well over my
head. Too much levels of complexity...

> 
> > open("/usr/lib/icedove/mathmail.cfg", O_RDONLY) = -1 ENOENT (No such file 
> > or directory)
> I don't know the content of your mathmail.cfg but if you want to set
> some specific settings for all Icedove users then put all of them in the
> file /etc/icedove/pref/icedove.js or a own file instead like intended
> with the file autoconf.js.

I tried putting all the stuff from my .cfg file to icedove.js It doesn't work.
>
> 
> Otherwise you have to symlink the file to /etc/icedove/pref/ every time
> you update the installation, or rebuild own packages.
> 

I wonder if a 
 dpkg-divert /usr/lib/icedove/mathmail.cfg
is enough to protect the file. 

Regards, Meik


-- 
Meik Hellmund 

Bug#807363: libkf5akonadicontact-dev: KF5AkonadiContactConfigVersion.cmake reports bad version

[Eric Valette]

Package: libkf5akonadicontact-dev
Version: 4:15.08.3-1
Severity: important

set(PACKAGE_VERSION "4.89.0") instead of 15.08.3

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

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

Versions of packages libkf5akonadicontact-dev depends on:
ii  libkf5akonadi-dev   4:15.08.3-1
ii  libkf5akonadicontact5   4:15.08.3-1
ii  libkf5calendarcore-dev  4:15.08.2-1
ii  libkf5contacts-dev  15.08.0-1

libkf5akonadicontact-dev recommends no packages.

libkf5akonadicontact-dev suggests no packages.

-- no debconf information

Bug#751282: pbuilder overrides keyring

[Mattia Rizzolo]

For the record, this has been in place since the aweful #751282

On Wed, Jun 11, 2014 at 08:33:18PM -0400, Phillip Susi wrote:
> On 06/11/2014 05:16 PM, Thorsten Glaser wrote:
> | Phillip Susi dixit:
> |
> |> specified in the suite script.  This breaks the creation of a pbuilder
> |> for ubuntu since the keyring is forced back to debian's.
> |
> | It doesn;t because you;re supposed to add --keyring to the command
> | line calling cowbuilder --create by yourself.
> 
> This makes no sense.  First, if you are going to specify it anyway,
> then it doesn't need to be in pbuilderrc, and second, why should you
> specify it when debootstrap already defaults to the correct value?

This annoys me too, since I constantly have to override the keyring
every time I build a chroot for something different than debian.

I want to have a look and triple check that deboostrap do the right
thing alone and it refuses to operate without a signed repository with a
recongnized key; if that's the case then I plan to remove that option
from the default debootstrap options.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#119911: ITP: alephone - marathon engine for data games

[Alexandre Detiste]

Le lundi 7 décembre 2015, 16:23:31 PICCORO McKAY Lenz a écrit :
> HEre are preliminary dsc sources for alephone engine
> 
> the game-data-packager has git entries for data (please are SCENARIOS) games
> 
> Alexander Detiste added a rule in G-D-P for Marthon, but that rule are
> too basic and lack of many missing necesary files
> 
> http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/commit/?id=276b4a06fb63b85be1db5069f0bc80620a1bc79e

I made these GDP package as dumb pas possible on purpose:

The way to go is also explained here in GDP code, quoting Simon in full.

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/game_data_packager/games/doom_common.py

Please do not follow this example for newly-supported games other than
the Doom family (Doom, Heretic, Hexen, Strife, Hacx, Chex Quest).

For new games it is probably better to use game-data-packager to ship only
the non-distributable files, and ship DFSG files (such as icons
and .desktop files) somewhere else.

One way is to have the engine package contain the wrapper scripts,
.desktop files etc. (e.g. src:openjk, src:iortcw). This is the simplest
thing if the engine is unlikely to be used for other games and alternative
engine versions are unlikely to be packaged.

Another approach is to have a package for the engine (like src:ioquake3)
and a package for the user-visible game (like src:quake, containing
wrapper scripts, .desktop files etc.). This is more flexible if the engine
can be used for other user-visible games (e.g. OpenArena, Nexuiz Classic)
or there could reasonably be multiple packaged engines (e.g. Quakespasm,
Darkplaces).

> game-data-packager produce with the engine, inside scenarios packages
> 3 .desktop files with a TryExec clause
> that point to a file provided by G-D-P -created, .deb
> for example /usr/share/games/marathon-{1|2|3}/try-exec
> but those are currently symlinks back to /usr/games/alephone , that
> are enought only for determine if can be lauched but NOT FOR lauch
> each game!

The TryExec and Exec aren't the same thing of course.

If you provide a .desktop file for each episode,
then each can call the engine directly without needing a wrapper script.

Bug#807362: tripwire segfaults on 32 bit 686-pae kernels

[James Stricherz]

Package: tripwire
Version: 2.4.2.2-5+b1
Severity: important

Dear Maintainer,

Tripwire segfaults on 32 bit 686-pae kernels. First, after an update,
I started investigating and came across this:

# strace tripwire
execve("/usr/sbin/tripwire", ["tripwire"], [/* 18 vars */]) = 0
uname({sysname="Linux", nodename="stat.fsu.edu", ...}) = 0
brk(0)  = 0x993b000
brk(0x993bd80)  = 0x993bd80
set_thread_area({entry_number:-1, base_addr:0x993b880, limit:1048575, 
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, 
useable:1}) = 0 (entry_number:6)
readlink("/proc/self/exe", "/usr/sbin/tripwire", 4096) = 18
brk(0x995cd80)  = 0x995cd80
brk(0x995d000)  = 0x995d000
access("/etc/ld.so.nohwcap", F_OK)  = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault

So on one machine I purged the package after backing up my policy
files and got this:

Generating site key (this may take several minutes)...  
/var/lib/dpkg/info/tripwire.postinst: line 108: 32578 Broken pipe ( 
echo "$site_pass"; sleep 2; echo "$site_pass" )
32579 Segmentation fault  | $twadmin -m G -S "$SITEKEYFILE" > /dev/null 2>&1

Doing an strace on twadmin gives this

# strace /usr/sbin/twadmin
execve("/usr/sbin/twadmin", ["/usr/sbin/twadmin"], [/* 17 vars */]) = 0
uname({sysname="Linux", nodename="spline", ...}) = 0
brk(0)  = 0x92d4000
brk(0x92d4d80)  = 0x92d4d80
set_thread_area({entry_number:-1, base_addr:0x92d4880, limit:1048575, 
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, 
useable:1}) = 0 (entry_number:6)
readlink("/proc/self/exe", "/usr/sbin/twadmin", 4096) = 17
brk(0x92f5d80)  = 0x92f5d80
brk(0x92f6000)  = 0x92f6000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault

Today's update works perfectly on the amd64 arch. Thanks.

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

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

Versions of packages tripwire depends on:
ii  debconf [debconf-2.0]   1.5.58
ii  postfix [mail-transport-agent]  2.11.3-1+b1

tripwire recommends no packages.

tripwire suggests no packages.

-- debconf information:
* tripwire/use-sitekey: true
* tripwire/use-localkey: true
  tripwire/email-report:
  tripwire/change-in-default-policy:
* tripwire/rebuild-config: false
  tripwire/local-passphrase-incorrect: false
* tripwire/rebuild-policy: false
  tripwire/installed:
  tripwire/upgrade: true
  tripwire/broken-passphrase:
  tripwire/site-passphrase-incorrect: false

Bug#751288: Avahi-daemon is noisy

[Stuart Prescott]

Package: avahi-daemon
Followup-For: Bug #751288

Dear Maintainer,

While travelling, I've found a couple of sites where there are a huge number
of clients on the network that generate dozens of Invalid response packet
messages per second. Fixing this in jessie would be really nice. Please
consider backporting the relevant fix in a stable update through
jessie-proposed-updates (in discussion with the release team, of course).

thanks!
Stuart

Bug#807249: needs versioned build dependency on python3-setuptools-scm

[Marc Haber]

On Mon, Dec 07, 2015 at 07:13:56PM +, Gianfranco Costamagna wrote:
> I honestly don't follow too much your approach :)
> 
> You called yourself out from the team, but you try to contribute anyway...

I use the package, and I do even dare doing my own backports, finding
issues, and reporting them.

> what about joining it again :D ?

I couldn't do too much to help. See, even my bug reports are wrong ;-)

> >setup.py demends python3-setuptool-scm >= 1.7, which is not satisfied
> >in Debian jessie.
> 
> it isn't satisfied even a lower version AFAIK (however it might be not true 
> for people apt-pinning stuff
> and not updating it)

You're right.

> >To make life less of python hell for backporters, please also declare
> >this versioned dependencies in debian/control so that one doesn't
> >spend hours guessing why package build fails.
> 
> while this is true in general, it doesn't change too much in this particular
> context. 1.7 is not part of any stable/testing/unstable Debian distribution, 
> and
> (since upstream asked this a while ago), I personally built&signed&uploaded 
> setuptools-scm
> for jessie backports (version 1.8)

Yes, this issue might have been caused by a local package of mine
built and used before borgbackup required a later version. I apologize
for my lack of python knowledge.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#807280: jessie-pu: package keepassx/0.4.3+dfsg-0.1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2015-12-06 at 19:33 -0500, Reinhard Tartler wrote:
> I'm writing you to request approving my recent upload of
> keepassx_0.4.3+dfsg-0.1+deb8u1. This update addresses
> CVE-2015-8378/#791858. I'm copying Moritz, since he asked me to prepare
> an upload to stable (I've already uploaded keepassx_0.4.3+dfsg-1, which
> also has a fix for this included, to unstable).

We generally prefer that things happen the other way around - the
discussion, then the upload.

In any case, flagged for acceptance, thanks.

Regards,

Adam

Bug#643997: aptitude: user-requested downgrade should not cause (so much of a) downgrade penalty for conflict resolution

[ydirson]

> 2011-10-01 15:59 Yann Dirson:
> >Package: aptitude
> >Version: 0.6.3-4
> >Severity: normal
> >
> >The "downgrade" use-case surely needs some love those days thanks to
> >the moz foundation: I rapidly had a test of iceweasel 7 in unstable
> >(eager to get better ram usage ;), just to conclude that so many
> >extensions are not compatible.
> >
> >So let's try to get back to v6... iceweasel-dbg has a scrict dep,
> >what
> >are the first suggestions from aptitude ?  Each of them summarized
> >below, one per paragraph.
> >
> >I originally thought it was just a problem of "downgrade" being
> >rated
> >too bad - and incidentally, when asked to explicitely downgrade,
> >aptitude should surely not inflict a downgrade-penalty to packages
> >that are broken by the downgrade.  But even then, how to explain
> >that
> >version from squeeze is elected first, then version from
> >moz.d.n/wheezy, and that just downgrading -dbg to wheezy itself is
> >not
> >even ever considerered, whereas the priority of those packages is
> >highest ?
> 
> From apt_preferences man page:
> 
>APT then applies the following rules, listed in order of
>precedence, to determine which version of a package to
>install.
> 
>· Never downgrade unless the priority of an available version
>  exceeds 1000. ("Downgrading" is installing a less recent
>  version of a package in place of a more recent version. Note
>  that none of APT's default priorities exceeds 1000; such
>  high
>  priorities can only be set in the preferences file. Note
>  also
>  that downgrading a package can be risky.)
> 
> So even if pin priority is higher, since none of them is higher than
> 1000, it's not supposed to facilitate downgrades in any way.
> 
> 
> More in general, downgrades are not supported, so I don't think that
> it
> should be a goal of aptitude or any other tool making this action
> very
> easy / convenient / appear risk-free by working as seamlessly as new
> installs or upgrades.

Just seen a situation which would not have astonished me, were it not for
this clarification about pinning: on a mostly-testing machine, where upgrading
tulip to new 4.8.0 from unstable (I had a pre-upload locally-built version of
that package installed, with same version string, but I'm not sure that makes
any difference) pulls binutils from unstable, breaking a couple of 
binutils-related versionned deps:

* the first suggestion is to remove tulip (the same kind of choice which puzzles
  me with downgrade: it has been marked for upgrade, why on earth is the *first*
  suggestion to do anything else than what was asked)
* then after I refused this choice for tulip, the next suggestion is to keep the
  currently installed version (same remark)
* then the next one is to upgrade binutils (and -dev and -multiarch), which is
  what I would have expected at first, BUT at the same time to DOWNGRADE
  binutils-arm-linux-gnueabi to the version in "stable"
* refusing that downgrade it finally proposes to upgrade the latter to unstable
  as well

That's the kind of situation to which I am routinely subject, and to which
unfortunately I usually don't pay that much attention any more.  But your
remark about pinning being the mechanism getting in the way of voluntary
downgrades, which perfectly made sense at the time, now confuses me, as I
don't see how it could cause a downgrade to be prefered to an upgrade.

Maybe the reason is linked to the identical score of 500 reported
by apt-cache policy ?

Bug#803490: jessie-pu: package pdns/3.4.1-4+deb8u4

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2015-12-05 at 19:11 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2015-10-30 at 16:05 +0100, Christian Hofstaedtler wrote:
> > there's a bug affecting pdns in stable (jessie): #798773
> > 
> > Upgrading -to- the jessie version from wheezy works fine, but
> > subsequent upgrades in jessie fail if users don't strip the config
> > file of comments.
> > 
> > This is quite bad for security updates, so please consider the
> > attached debdiff.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#804208: jessie-pu: package fuse-exfat/1.1.0-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2015-12-06 at 13:51 +0100, Sven Hoexter wrote:
> On Sat, Dec 05, 2015 at 07:13:42PM +, Adam D. Barratt wrote:
> 
> Hi Adam,
> 
> > Please go ahead.
> 
> Uploaded a minute ago.

Flagged for acceptance.

Regards,

Adam

Bug#807361: libkf5calendarcore-dev: bad version number in KF5CalendarCoreConfigVersion.cmake

[Eric Valette]

Package: libkf5calendarcore-dev
Version: 4:15.08.2-1
Severity: important

KF5CalendarCoreConfigVersion.cmake has a version equal to 4.82.0. I just do not
get the numbering sheme and digikam compilation fails because of that.

Why not 15.08.2?

set(PACKAGE_VERSION "4.82.0")

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

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

Versions of packages libkf5calendarcore-dev depends on:
ii  libical-dev1.0.1-0.1
ii  libkf5calendarcore54:15.08.2-1
ii  libkf5kdelibs4support-dev  5.16.0-1

libkf5calendarcore-dev recommends no packages.

libkf5calendarcore-dev suggests no packages.

-- no debconf information

Bug#807040: your mail

[Julien Cristau]

On Mon, Dec  7, 2015 at 21:37:34 +0100, Tomas Pospisek wrote:

> On Mon, 7 Dec 2015, Julien Cristau wrote:
> 
> >On Mon, Dec  7, 2015 at 11:13:54 +0100, Tomas Pospisek wrote:
> >
> >>reassign 807040 xserver-xorg-video-nouveau
> >>
> >Please don't do that.
> 
> OK. Why not? Both the original report and the follow up comment seemed to
> indicate that it could be the nouveau driver.
> 
> Should I instead close the bug report and point the reporter to the usual
> Debian support options to provide more substanciated report?
> 
> I would be happy to have your advice along with the reasoning behind it.
> 
Yes, closing such a report is better, since as it is it's essentially
void of any useful information.  Not to mention 1) a kernel panic is not
a userspace bug, and 2) the reassign message provided no
context/information for the receiving party.

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#807360: debci-worker: cronjob exits with error after package removal

[Andreas Beckmann]

Package: debci-worker
Version: 1.0
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your packages cronjob exits with
error after the package has been removed.

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

1m51.0s INFO: Package debci-worker contains cron file: 
/etc/cron.daily/debci-worker
1m51.0s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpPXxCGe', 
'/etc/cron.daily/debci-worker']
1m51.0s DUMP: 
  /etc/cron.daily/debci-worker: 13: /etc/cron.daily/debci-worker: debci: not 
found
1m51.0s ERROR: Command failed (status=127): ['chroot', 
'/tmp/piupartss/tmpPXxCGe', '/etc/cron.daily/debci-worker']


cheers,

Andreas


debci-worker_1.0.log.gz
Description: application/gzip

Bug#807359: requires root: install with suid or capabilities

[Antoine Beaupré]

Package: physlock
Version: 0.4.5-1
Severity: wishlist

physlock doesn't work out of the box for regular users:

$ physlock
physlock: must be root!

shouldn't this be installed with capabilities or suid?

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable'), (500, 'oldstable'), (1, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages physlock depends on:
ii  libc6  2.19-18+deb8u1

physlock recommends no packages.

physlock suggests no packages.

-- no debconf information

Bug#804499: ruby-gsl: GSL transition requires rebuild

[Sebastiaan Couwenberg]

On Wed, 18 Nov 2015 12:16:24 +0100 Balint Reczey  wrote:
> I have prepared the fix in git [2] but tamuanova [3] needs to be transitioned
> first since it is a build dependency and can't be installed together with
> libgsl-dev > 2.0.

Thanks to Anton Gladky tamuanova has been updated for GSL 2, that
removes it as a blocker for this issue.

Kind Regards,

Bas

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

Bug#807040: your mail

[Tomas Pospisek]

On Mon, 7 Dec 2015, Julien Cristau wrote:


On Mon, Dec  7, 2015 at 11:13:54 +0100, Tomas Pospisek wrote:


reassign 807040 xserver-xorg-video-nouveau


Please don't do that.


OK. Why not? Both the original report and the follow up comment seemed 
to indicate that it could be the nouveau driver.


Should I instead close the bug report and point the reporter to the usual 
Debian support options to provide more substanciated report?


I would be happy to have your advice along with the reasoning behind it.

Thanks Julien,
*t

Bug#807358: locales: /usr/sbin/locale-gen: line 62: 31200 Killed (64 Mb RAM)

[Jari Aalto]

Package: locales
Version: 2.19-22
Severity: important

Unable to install package "locales" or generate locales manually on
x86 with 64 Mb and plenty of free swap. Output of htop(1):

  CPU[|||  11.1%] Tasks: 38, 0 thr; 
1 running
  Mem[|||29/56MB] Load average: 
0.17 2.59 2.14
  Swp[||21/760MB] Uptime: 634 
days(!), 20:34:35
 

  $ locale-gen
  Generating locales (this might take a while)...
  en_US.UTF-8.../usr/sbin/locale-gen: line 62: 31200 Killed
localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale
 done
 Generation complete.

System has only en_US.UTF-8 activated:

 $ grep -v '#' /etc/locale.gen
 en_US.UTF-8 UTF-8

Debug listing:


  $ sh -x locale-gen
  [...]
  + '[' -f /usr/local/share/i18n/locales/en_US ']'
  + localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8
  /usr/sbin/locale-gen: line 62: 31157 Killed  localedef -i 
$input -c -f $charset -A /usr/share/locale/locale.alias $locale
  + :
  + echo ' done'
done
  [...]
  Killed

Manual try:

  $ localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8
  <... time passes>
  Killed
  
I don't have possibilities to install any trace tools in this low
memory system.

Possibly related:

  https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/202959

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  libc-bin   2.19-22

locales recommends no packages.

locales suggests no packages.

-- debconf-show failed
+ set -e
+ LOCALEGEN=/etc/locale.gen
+ LOCALES=/usr/share/i18n/locales
+ USER_LOCALES=/usr/local/share/i18n/locales
+ '[' -n y ']'
+ unset POSIXLY_CORRECT
+ '[' -f /etc/locale.gen ']'
+ '[' -s /etc/locale.gen ']'
+ KEEP=
+ '[' '' = --keep-existing ']'
+ '[' -z '' ']'
+ rm -rf /usr/lib/locale/locale-archive
+ umask 022
+ echo 'Generating locales (this might take a while)...'
Generating locales (this might take a while)...
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue
+ read locale charset
+ case $locale in
+ continue

Bug#807357: libtest-autoloader-perl: test suite fails in non-English locales

[Niko Tyni]

Package: libtest-autoloader-perl
Version: 0.03-2
Severity: important
Tags: patch
User: reproducible-bui...@lists.debian.org
Usertags: ftbfs locale
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=62839
X-Debbugs-Cc: reproducible-bui...@lists.debian.org

This package fails to build in non-English locales, because
t/00basic.t hardcodes English error messages.

This can be fixed either by setting LC_ALL=C in debian/rules or by using
setlocale(LC_ALL, 'C') in t/00basic.t. The latter requires the POSIX
module; in this case the test script already loads it, so I picked that
option. Patch attached (and already forwarded upstream.)
-- 
Niko Tyni   nt...@debian.org

Bug#119911: ITP: alephone - marathon engine for data games

[PICCORO McKAY Lenz]

HEre are preliminary dsc sources for alephone engine

the game-data-packager has git entries for data (please are SCENARIOS) games

Alexander Detiste added a rule in G-D-P for Marthon, but that rule are
too basic and lack of many missing necesary files

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/commit/?id=276b4a06fb63b85be1db5069f0bc80620a1bc79e

game-data-packager produce with the engine, inside scenarios packages
3 .desktop files with a TryExec clause
that point to a file provided by G-D-P -created, .deb
for example /usr/share/games/marathon-{1|2|3}/try-exec
but those are currently symlinks back to /usr/games/alephone , that
are enought only for determine if can be lauched but NOT FOR lauch
each game!

Thats are not enought to made work each scenario, due each scenario
are independent data game and works without any other data, its not
same as other engines & data's that need original files for work

Each scenario to work need that be parsed as LAST argument  to the
engine, this avoid modification of the environment using the
ALEPHONE_DATA variable

the script that i provide solves that: see the already provide manpage
for usage, just symlink each lauch tho the script and that all, can be
included in the engine package but i prefer a common package produced
by game-data-packager or something like quake does (a meta empty that
depends/recommends both data and engine)

the dsc sources that i provide has inside all the necesary to promote
the engine package

PLEASE NOTE THAT MENTORS HAVE A PROBLEM WITH KEY GPG VALIDATION AND I
MAIL IN TWO OPORTUNITIES WITH OUT ANY REPLY ABOUT!


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


marathon-laucher.sh
Description: Bourne shell script


marathon-laucher.sh
Description: Bourne shell script


marathon-launcher.6
Description: Binary data


alephone_20150620-0.dsc
Description: Binary data


alephone_20150620-0.debian.tar.xz
Description: application/xz

Bug#801798: [buildd-tools-devel] Bug#801798: Bug#801798: please support building package without generating a gpg key for sbuild

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2015-12-07 21:13:10)
> It seems that apt has support for trusted=yes since 0.8.16~exp3, so since
> wheezy.

keeping support for signing the internal repository is important for as long as
we want to support squeeze. When running sbuild, then the apt *inside* the
chroot has to support [trusted=yes]. Since today on stretch or unstable we want
to be able to build packages in a squeeze chroot for old-old-stable, we must
keep the functionality of signing the internal repo until we stop supporting
squeeze.

So I suggest to add a command line flag like --trust-internal-repo which will
make sbuild not require keys anymore and will set [trusted=yes] in apt's
sources.list. Once we drop support for squeeze we can make that command line
flag a no-op and never use keys for the internal repository by default.

Does this make sense?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#807148: glx-diversions: ffmpeg looks for libGL.so.1 while glx-diversions offers only libGL.so

[Andreas Beckmann]

Control: tag -1 moreinfo unreproducible

On 2015-12-07 20:07, Luca Boccassi wrote:
> On Sat, 2015-12-05 at 22:17 -0500, Xinyue Lu wrote:
>> I've noticed that my ffmpeg doesn't work and reporting missing shared
>> library libGL.so.1.

> I had a look but cannot reproduce this on either of my systems.
> libGL.so.1 is correctly installed by update-alternatives when
> mesa-diverted is configured.

I cannot reproduce this either.

I could only think of one case: glx-diversions is installed but not any
of the glx-alternative-{mesa,nvidia,fglrx} packages. But that must have
been a manual install since anything depending on glx-diversions (some
bits of a non-free graphics driver) will depend on (at least) one of
glx-alternative-*, too.
And glx-diversions also Recommends: glx-alternative-mesa, so if you end
up without any alternatives, this must have been done conciously.


Andreas

Bug#802579: binutils changed ld.bfd / ld.gold files and symlinks

[Sven Joachim]

On 2015-12-07 11:39 +0800, YunQiang Su wrote:

> On Sat, 14 Nov 2015 02:20:40 +0100 Matthias Klose  wrote:
>> Control: severity -1 serious
>>
>> binutils built from the 2.26 branch is now in unstable.
>>
>>
>
> I uploaded this packages with the attached patch to 3-days delay.

Thanks for taking care of hardening-wrapper, but I am afraid your
changes are not quite correct.

> diff -Nru hardening-wrapper-2.7/debian/hardening-wrapper.links 
> hardening-wrapper-2.8+nmu1/debian/hardening-wrapper.links
> --- hardening-wrapper-2.7/debian/hardening-wrapper.links  2013-09-14 
> 03:55:36.0 +0800
> +++ hardening-wrapper-2.8+nmu1/debian/hardening-wrapper.links 2015-12-07 
> 11:33:14.0 +0800
> @@ -1,12 +1,13 @@
>  #!/bin/sh
>  # programatically build links (change debian/h-w.{preinst,postrm} too)
> -for ver in 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9
> +eval $(dpkg-architecture -a)
> +for ver in 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5
>  do
>  echo usr/bin/hardened-cc usr/bin/gcc-$ver
>  echo usr/bin/hardened-c++ usr/bin/g++-$ver
>  done
>  cat < -usr/bin/hardened-ld usr/bin/ld.bfd
> -usr/bin/hardened-ld usr/bin/ld.gold
> +usr/bin/hardened-ld usr/bin/${DEB_BUILD_MULTIARCH}-ld.bfd
> +usr/bin/hardened-ld usr/bin/${DEB_BUILD_MULTIARCH}-ld.gold

DEB_BUILD_MULTIARCH is not the right variable, you want
DEB_HOST_GNU_TYPE instead - except on {,kfreebsd-,hurd-}i386, where
binutils is configured for i686{-linux,-kfreebsd,}-gnu rather than
i586{-linux,-kfreebsd,}-gnu currently reported by dpkg-architecture.

> diff -Nru hardening-wrapper-2.7/debian/hardening-wrapper.postrm 
> hardening-wrapper-2.8+nmu1/debian/hardening-wrapper.postrm
> --- hardening-wrapper-2.7/debian/hardening-wrapper.postrm 2013-09-14 
> 03:55:52.0 +0800
> +++ hardening-wrapper-2.8+nmu1/debian/hardening-wrapper.postrm
> 2015-12-07 10:48:44.0 +0800
> @@ -6,17 +6,19 @@
>   --rename --remove /usr/bin/"$1" || true
>  }
>  
> +eval $(dpkg-architecture -a)

You can't really use dpkg-architecture in maintainer scripts, since
hardening-wrapper does not depend on dpkg-dev.  Even if it were to do
that, the result is not necessarily correct, e.g. hardening-wrapper
could have a different architecture than dpkg.

Cheers,
   Sven

Bug#807356: salt: CVE-2015-8034: Saving state.sls cache data to disk with insecure permissions

[Salvatore Bonaccorso]

Source: salt
Version: 2015.8.1+ds-2
Severity: important
Tags: security upstream patch
Forwarded: https://github.com/saltstack/salt/issues/28455

Hi,

the following vulnerability was published for salt.

CVE-2015-8034[0]:
information leak from state.sls cache data stored as world-readable

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-2015-8034
[1] https://github.com/saltstack/salt/issues/28455
[2] 
https://github.com/cachedout/salt/commit/097838ec0c52b1e96f7f761e5fb3cd7e79808741

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#807284: gitolite3: FSHify gitolite3

[Christoph Anton Mitterer]

Control: notfound -1 2.3-1
Control: found -1 3.6.4-1


On Mon, 2015-12-07 at 09:04 -0400, David Bremner wrote:
> Package: gitolite3
> > Version: 2.3-1
> 
> BTW, this version is wrong.
hmm weird... no idea how I got that in ^^



> > The obvious next thing would probably be to move
> > ~git/.gitolite/logs/
> > to /var/logs/gitolite3 (respectively symlink it) and perhaps to add
> > proper logrotation config.
> 
> This is already easily configurable by the admin: see
>  
>  http://gitolite.com/gitolite/gitolite.html#appendix-3-v3.6.1-sys
> log
Sure.. the point is just, Debian should do that perhaps out-of-the box.


> At the moment I don't see an elegant way of changing defaults in
> gitolite.rc; I'll discuss that with upstream.
Maybe simply symlink the logs dir?


> 
> > What I did there, personally, is that I basically created a clone
> > of
> > the admin repo in /etc, i.e.  /etc/gitolite (well actually I've
> > named
> > it /etc/local/gitolite to avoid any future conflicts).  Not sure if
> > this seems like a proper way to go for the package, i.e. that it
> > automatically creates a clone a /etc that the user may use.
> 
> In general I prefer to avoid divergence from upstream, unless there
> is a
> contradiction with policy MUST.
Well I guess we're at a corner case here: The policy, IIRC, says that
FHS must be followed (more or less)... FHS in turn says: configuration
goes to /etc.
Obviously gitolite has two kinds of config:
1) the canonical config which can be anywhere in any number of admin
repo clones
2) the current state of the config (which IMHO should really be in
/var, as it is).


>  For me it also doesn't make sense to
> force the day to day administration (editing of config,
> adding/deleting
> user keys) to use root on the server. Having files in /etc/ editable
> by
> non-root is also a bit strange (and what user should be able to edit
> them?).
Sure... one could also simply say, that gitolite doesn't have that
classic in-/etc  as in (1) above... and that we keep things here as is,
and define no standard location which the user may not use anyway.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#805222: [Pkg-php-pecl] Bug#805222: php-apcu: FTBFS: PHP Fatal error: Call to a member function getFilelist() on null

[Mathieu Parent (Debian)]

2015-12-07 17:21 GMT+01:00 Ondřej Surý :
> Control: reassign -1 php-pear
> Control: found -1 php-pear/5.6.16+dfsg-1
> Control: affects -1 php5-apcu
>
> Hi,
>
> thank you for the report, after some debugging it seems this is a
> generic error in PEAR instead of bug just in the php-apcu. This should
> not affect no users, but it probably broke all PHP extensions, since it
> stops honoring packagingroot after calling PEAR_Registry->setConfig()
>
> I have a fix ready and PHP building, and I am ccing Fedora and SuSE
> maintainers.
>
> Mathieu, this also applies to your standalone src:php-pear:

OK thanks.

> diff --git a/PEAR/Command/Install.php b/PEAR/Command/Install.php
> index 9d572ed..3b1fec9 100644
> --- a/PEAR/Command/Install.php
> +++ b/PEAR/Command/Install.php
> @@ -848,7 +848,7 @@ Run post-installation scripts in package ,
> if any exist.
>  $pkg = &$instreg->getPackage($param->getPackage(),
>  $param->getChannel());
>  // $pkg may be NULL if install is a 'fake' install via
>  --packagingroot
>  if (is_object($pkg)) {
> -$pkg->setConfig($this->config);
> +$pkg->setConfig($this->config, false);
>  if ($list = $pkg->listPostinstallScripts()) {
>  $pn =
>  $reg->parsedPackageNameToString(array('channel' =>
> $param->getChannel(), 'package' =>
> $param->getPackage()), true);
>
>
> This fixes the issue right now, but it should be probably reported
> upstream to have a correct fix (since this might break other stuff :)),
> but my PEAR account doesn't work right now, so it might take me a while
> to report this to upstream.

You can propose a PR instead: https://github.com/pear/pear-core/pulls

Cheers
-- 
Mathieu Parent

Bug#807355: python-django-compressor: FTBFS: ImportError: cannot import name unittest

[Chris Lamb]

Source: python-django-compressor
Version: 1.5-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-django-compressor fails to build from source in unstable/amd64:

  [..]  
  
  ==
  ERROR: compressor.tests.test_filters
  (unittest.loader.ModuleImportFailure)
  --
  ImportError: Failed to import test module:
  compressor.tests.test_filters
  Traceback (most recent call last):
File "/usr/lib/python2.7/unittest/loader.py", line 254, in
_find_tests
  module = self._get_module_from_name(name)
File "/usr/lib/python2.7/unittest/loader.py", line 232, in
_get_module_from_name
  __import__(name)
File

"/home/lamby/temp/cdt.20151207220219.jZR1UtVc3q/python-django-compressor-1.5/compressor/tests/test_filters.py",
line 10, in 
  from django.utils import unittest
  ImportError: cannot import name unittest
  
  
  --
  Ran 98 tests in 0.200s
  
  FAILED (errors=56)
  Creating test database for alias 'default'...
  Destroying test database for alias 'default'...
  debian/rules:19: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory
  '/home/lamby/temp/cdt.20151207220219.jZR1UtVc3q/python-django-compressor-1.5'
  debian/rules:11: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


python-django-compressor.1.5-3.unstable.amd64.log.txt.gz
Description: Binary data

Bug#801798: [buildd-tools-devel] Bug#801798: Bug#801798: please support building package without generating a gpg key for sbuild

[Johannes Schauer]

Hi all,

Quoting Benjamin Drung (2015-12-07 12:37:01)
> Am Donnerstag, den 15.10.2015, 23:54 +0200 schrieb Helmut Grohne:
> > On Wed, Oct 14, 2015 at 06:53:56PM +0200, Helmut Grohne wrote:
> > > I would like to be able to use sbuild without having to create a gpg key
> > > for it. I understand that creating a key is required for operating as a
> > > buildd, but sbuild can be used in other scenarios as well. This bug is
> > > supposed to summarize a discussion I had with Johannes Schauer and
> > > Wookey.
> > 
> > Johannes Schauer asked me to clarify why this change is useful.
> > Currently, every setup of sbuild requires running sbuild-update
> > --keygen. This step is not done from a maintainer script and thus prone
> > to be forgotten. It also takes up to an hour to execute on virtual
> > machines that lack proper random sources.
> > 
> > I am attaching a basic and untested patch that implements the following
> > change: If sbuild fails to find the keys (for instance because
> > sbuild-update --keygen has not been run), it no longer errors out, but
> > adds "[ trusted=yes ]" to the generated sources.list. Thus existing
> > installations (with existing keys) will keep operating like they did and
> > new installations may skip the key generation step. The patch is meant
> > to sketch the desired behaviour.
> 
> Adding cases complicates the code. So why not just change the behavior to
> always use "[ trusted=yes ]"?

with apt's support for [trusted=yes] lines in sources.list I cannot think of a
reason why one would want to sign the internal repository.

Is anybody able to come up with a reason?

Otherwise it might indeed make sense to just never sign that repository. It's a
local file:// repository so there should not be any security problems.

Maybe the signing of the internal repository came from a time where apt didn't
have the trusted=yes option?

It seems that apt has support for trusted=yes since 0.8.16~exp3, so since
wheezy.

Is there any reason to keep support for squeeze?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#807354: passenger: CVE-2015-7519: Header overwriting issue

[Salvatore Bonaccorso]

Source: passenger
Version: 5.0.7-3
Severity: important
Tags: security upstream patch

Hi,

the following vulnerability was published for passenger.

CVE-2015-7519[0]:
Header overwriting issue

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-2015-7519
[1] https://bugzilla.suse.com/show_bug.cgi?id=956281
[2] 
https://github.com/phusion/passenger/commit/ddb8ecc4ebf260e4967f57f271d4f5761abeac3e

Regards,
Salvatore

Bug#807246: Still doesn't work properly with local PostgreSQL

[Paul Gevers]

Control: clone -1 -2
Control: tags -1 confirmed
Control: retitle -2 reconfigure doesn't recover properly from errors
Control: retitle -1 127.0.0.1 isn't recognized as localhost for ident

Ouch, this is very bad. And yes, I now see that I missed 127.0.0.1 as
localhost in my new logic to improve the PostgreSQL situation. I wonder
where to find which IP addresses I should check that may actually be
considered to be localhost.

On 06-12-15 17:30, Andrey Rahmatullin wrote:
> So, I upgraded dbconfig-common and tt-rss and dpkg-reconfigure is still 
> failing.

Just out of curiosity, where exactly does "still" refer to?

> It also continues even after I said "Abort" (four times) and that's probably
> how I got my DB dropped (without a backup, as it failed to produce one;

I don't see the DB dropping happening in your logging, or am I
overseeing something? (And how can the DB be dropped if the dbadmin
can't log in anyways?) The fact that you have to abort four times is a
bug on it's own and I have cloned this bug to mark that. If you can show
me that the DB was dropped, that is worth a new bug.

> A sample session with debug enabled:

Much thanks.

And why

> dbconfig-common: tt-rss configure: aborted.

leads to:

> dbconfig-common: dropping old pgsql database ttrss.

is currently a mystery, but I'll investigate.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#807352: Subject: linux-image-3.16.0-4-amd64: kernel BUG at smpboot.c:134

[Mike Waychison]

Package: src:linux
Version: 3.16.7-ckt11-1+deb8u5
Severity: important
Tags: upstream

Dear Maintainer,

We have identified a failure in this kernel version to boot with low
probability on Google Compute Engine, and have traced the issue back to a bug
in upstream that has since been fixed.  Please integrate the following upstream
commit.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dd9d3843755da95f63dd3a376f62b3e45c011210

sched: Fix cpu_active_mask/cpu_online_mask race
There is a race condition in SMP bootup code, which may result
in

WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
workqueue_cpu_up_callback()
or
kernel BUG at kernel/smpboot.c:135!

It can be triggered with a bit of luck in Linux guests running
on busy hosts.

 CPU0 CPUn
  

 _cpu_up()
   __cpu_up()
start_secondary()
  set_cpu_online()
 cpumask_set_cpu(cpu,
 to_cpumask(cpu_online_bits));
   cpu_notify(CPU_ONLINE)
 
 cpumask_set_cpu(cpu,
 to_cpumask(cpu_active_bits));

During the various CPU_ONLINE callbacks CPUn is online but not
active. Several things can go wrong at that point, depending on
the scheduling of tasks on CPU0.

Variant 1:

  cpu_notify(CPU_ONLINE)
workqueue_cpu_up_callback()
  rebind_workers()
set_cpus_allowed_ptr()

  This call fails because it requires an active CPU; rebind_workers()
  ends with a warning:

WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
workqueue_cpu_up_callback()

Variant 2:

  cpu_notify(CPU_ONLINE)
smpboot_thread_call()
  smpboot_unpark_threads()
   ..
__kthread_unpark()
  __kthread_bind()
  wake_up_state()
   ..
select_task_rq()
  select_fallback_rq()

  The ->wake_cpu of the unparked thread is not allowed, making a call
  to select_fallback_rq() necessary. Then, select_fallback_rq() cannot
  find an allowed, active CPU and promptly resets the allowed CPUs, so
  that the task in question ends up on CPU0.

  When those unparked tasks are eventually executed, they run
  immediately into a BUG:

kernel BUG at kernel/smpboot.c:135!

Just changing the order in which the online/active bits are set
(and adding some memory barriers), would solve the two issues
above. However, it would change the order of operations back to
the one before commit 6acbfb96976f ("sched: Fix hotplug vs.
set_cpus_allowed_ptr()"), thus, reintroducing that particular
problem.

Going further back into history, we have at least the following
commits touching this topic:
- commit 2baab4e90495 ("sched: Fix select_fallback_rq() vs
cpu_active/cpu_online")
- commit 5fbd036b552f ("sched: Cleanup cpu_active madness")

Together, these give us the following non-working solutions:

  - secondary CPU sets active before online, because active is assumed to
be a subset of online;

  - secondary CPU sets online before active, because the primary CPU
assumes that an online CPU is also active;

  - secondary CPU sets online and waits for primary CPU to set active,
because it might deadlock.

Commit 875ebe940d77 ("powerpc/smp: Wait until secondaries are
active & online") introduces an arch-specific solution to this
arch-independent problem.

Now, go for a more general solution without explicit waiting and
simply set active twice: once on the secondary CPU after online
was set and once on the primary CPU after online was seen.

set_cpus_allowed_ptr()")



-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc
version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64
root=UUID=f5d73494-1cf2-4811-8e2d-67884d4bd6e7 ro
console=ttyS0,38400n8 elevator=noop console=hvc0

** Not tainted

** Kernel log:
[0.562395] sd 0:0:1:0: [sda] 20971520 512-byte logical blocks:
(10.7 GB/10.0 GiB)
[0.563436] sd 0:0:1:0: [sda] 4096-byte physical blocks
[0.564355] sd 0:0:1:0: [sda] Write Protect is off
[0.565007] sd 0:0:1:0: [sda] Mode Sense: 1f 00 00 08
[0.565054] sd 0:0:1:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[0.567526]  sda: sda1
[0.568469] sd 0:0:1:0: [sda] Attached SCSI disk
[0.569459] sd 0:0:1:0: Attached scsi generic sg0 type 0
[0.680208] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input0
[0.699765] EXT4-fs (sda1): mounted filesystem with ordered data
mode. Opts: (null)
[0.797732] systemd[1]: systemd 215 running in system mode. (+PAM
+AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
-SECCOMP -APPARMOR)
[0.799627] systemd[1]: Detected virtualization 'kvm'.
[0.800379] systemd[1]: Detected architecture 'x86-64'.
[0.851257] systemd[1]: Inserted module 'autofs4'
[0.852140] systemd[1]: No hostname configured.
[0.852805] systemd[1]: Set hostname to .
[0.970228] systemd[1]: Cannot add dependency 

Bug#807351: python-debian: FTBFS: SystemError: E:Unable to parse package file (1)

[Chris Lamb]

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

Dear Maintainer,

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

  [..]
  test_reverse (test_debtags.TestDebtags) ... ok
  
  ==
  ERROR: apt_pkg does not support comments within multiline fields
  --
  Traceback (most recent call last):
File

"/home/lamby/temp/cdt.20151207220143.ZwB98jWQ6C/python-debian-0.1.27/tests/test_deb822.py",
line 922, in test_iter_paragraphs_comments_use_apt_pkg
  fh, use_apt_pkg=True))
File "../lib/debian/deb822.py", line 376, in iter_paragraphs
  for section in parser:
  SystemError: E:Unable to parse package file  (1)
  
  --
  Ran 166 tests in 0.371s
  
  FAILED (errors=1)
  debian/rules:28: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory
  '/home/lamby/temp/cdt.20151207220143.ZwB98jWQ6C/python-debian-0.1.27'
  debian/rules:13: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


python-debian.0.1.27.unstable.amd64.log.txt.gz
Description: Binary data

Bug#807350: django-restricted-resource: FTBFS with Django 1.9: django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.

[Chris Lamb]

Source: django-restricted-resource
Version: 2015.11-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

django-restricted-resource fails to build from source in unstable/amd64:

  [..]

  self.run_command(cmd)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in
run_command
  cmd_obj.run()
File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py",
line 157, in run
  self.with_project_on_sys_path(self.run_tests)
File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py",
line 138, in with_project_on_sys_path
  func()
File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py",
line 178, in run_tests
  testRunner=self._resolve_as_ep(self.test_runner),
File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__
  self.parseArgs(argv)
File "/usr/lib/python2.7/unittest/main.py", line 149, in parseArgs
  self.createTests()
File "/usr/lib/python2.7/unittest/main.py", line 158, in createTests
  self.module)
File "/usr/lib/python2.7/unittest/loader.py", line 130, in
loadTestsFromNames
  suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib/python2.7/unittest/loader.py", line 115, in
loadTestsFromName
  test = obj()
File

"/home/lamby/temp/cdt.20151207215919.KS07bteFb8/django-restricted-resource-2015.11/django_restricted_resource/test_project/tests.py",
line 24, in run_tests
  return
  run_tests_for("django_restricted_resource.test_project.settings")
File "/usr/lib/python2.7/dist-packages/django_testproject/tests.py",
line 58, in run_tests_for
  failures = runner(test_labels)
File "/usr/lib/python2.7/dist-packages/django/test/runner.py", line
532, in run_tests
  old_config = self.setup_databases()
File "/usr/lib/python2.7/dist-packages/django/test/runner.py", line
482, in setup_databases
  self.parallel, **kwargs
File "/usr/lib/python2.7/dist-packages/django/test/runner.py", line
726, in setup_databases
  serialize=connection.settings_dict.get("TEST",
  {}).get("SERIALIZE", True),
File
"/usr/lib/python2.7/dist-packages/django/db/backends/base/creation.py",
line 70, in create_test_db
  run_syncdb=True,
File
"/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
line 91, in call_command
  app_name = get_commands()[name]
File "/usr/lib/python2.7/dist-packages/django/utils/lru_cache.py",
line 100, in wrapper
  result = user_function(*args, **kwds)
File
"/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
line 71, in get_commands
  for app_config in reversed(list(apps.get_app_configs())):
File "/usr/lib/python2.7/dist-packages/django/apps/registry.py",
line 137, in get_app_configs
  self.check_apps_ready()
File "/usr/lib/python2.7/dist-packages/django/apps/registry.py",
line 124, in check_apps_ready
  raise AppRegistryNotReady("Apps aren't loaded yet.")
  django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.
  debian/rules:8: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory
  
'/home/lamby/temp/cdt.20151207215919.KS07bteFb8/django-restricted-resource-2015.11'
  debian/rules:4: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


django-restricted-resource.2015.11-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#807348: libgnutls-deb0-28: In multiarch, 3.3.19-1:i386 conflict with 3.3.18-1:amd64

[Serge Kilimoff-Goriatchkine]

Package: libgnutls-deb0-28
Version: 3.3.19-1
Severity: important

Dear Maintainer,

When I want install playonlinux (by example) on my Debian SID, I have the 
follow message :

 libgnutls-deb0-28 : Casse: libgnutls-deb0-28:i386 (!= 3.3.18-1) mais 3.3.19-1 
doit être installé.
 libgnutls-deb0-28:i386 : Casse: libgnutls-deb0-28 (!= 3.3.19-1) mais 3.3.18-1 
est installé.

(Sorry, my system is configurated for used french language)

For the moment, the version 3.3.19-1 does not exists for arch amd64.

Thanks ! And good luck, dear maintener.


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

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

Bug#807347: txaws: FTBFS: twisted.trial.unittest.FailTest: '500' != 500

[Chris Lamb]

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

Dear Maintainer,

txaws fails to build from source in unstable/amd64:

  [..]
  
  txaws.ec2.tests.test_client.QueryTestCase.test_submit_non_EC2_400
  
===
  [FAIL]
  Traceback (most recent call last):
File

"/home/lamby/temp/cdt.20151207215711.OLxXnJQQOq/txaws-0.2.3/txaws/tests/test_exception.py",
line 18, in test_creation
  self.assertEquals(error.status, 500)
File "/usr/lib/python2.7/dist-packages/twisted/trial/_synctest.py",
line 437, in assertEqual
  super(_Assertions, self).assertEqual(first, second, msg)
File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
  assertion_func(first, second, msg=msg)
File "/usr/lib/python2.7/unittest/case.py", line 506, in
_baseAssertEqual
  raise self.failureException(msg)
  twisted.trial.unittest.FailTest: '500' != 500
  
  txaws.tests.test_exception.AWSErrorTestCase.test_creation
  
---
  Ran 437 tests in 0.633s
  
  FAILED (skips=56, failures=9, successes=372)
  debian/rules:14: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory
  '/home/lamby/temp/cdt.20151207215711.OLxXnJQQOq/txaws-0.2.3'
  debian/rules:6: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


txaws.0.2.3-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#807349: dwww: FTBFS: error: expected identifier or '(' before '__extension__'

[Chris Lamb]

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

Dear Maintainer,

dwww fails to build from source in unstable/amd64:

  [..]

  gcc -c -D_FORTIFY_SOURCE=2 -DVERSION='"1.12.1"' -g -O2
  -fstack-protector-strong -Wformat -Werror=format-security -Wall
  -Wextra -Wstrict-prototypes -Wmissing-prototypes -Werror -g  -o
  _build/dwww-cache.o dwww-cache.c
  In file included from /usr/include/string.h:634:0,
   from dwww-cache.c:30:
  /usr/include/publib/strutil.h:67:7: error: expected identifier or '('
  before '__extension__'
   char *strndup(const char *, size_t);
 ^
  Makefile:25: recipe for target '_build/dwww-cache.o' failed
  make[2]: *** [_build/dwww-cache.o] Error 1
  common.mk:190: recipe for target 'all' failed
  make[1]: *** [all] Error 2
  make[1]: Leaving directory
  '/home/lamby/temp/cdt.20151207215750.Wr0BRL256Q/dwww-1.12.1'
  dh_auto_build: make -j1 returned exit code 2
  debian/rules:12: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


dwww.1.12.1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#807346: python-django-openstack-auth: FTBFS:

[Chris Lamb]

Source: python-django-openstack-auth
Version: 2.0.0-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-django-openstack-auth fails to build from source in
unstable/amd64:

  [..]
  
  ==
  ERROR: test_switch_with_next (tests.OpenStackAuthTestsV3)
  --
  Traceback (most recent call last):
File

"/home/lamby/temp/cdt.20151207215322.HOuGTibadH/python-django-openstack-auth-2.0.0/openstack_auth/tests/tests.py",
line 732, in test_switch_with_next
  self.test_switch(next='/next_url')
File

"/home/lamby/temp/cdt.20151207215322.HOuGTibadH/python-django-openstack-auth-2.0.0/openstack_auth/tests/tests.py",
line 720, in test_switch
  response = self.client.get(url, form_data)
File "/usr/lib/python2.7/dist-packages/django/test/client.py", line
503, in get
  **extra)
File "/usr/lib/python2.7/dist-packages/django/test/client.py", line
304, in get
  return self.generic('GET', path, secure=secure, **r)
File "/usr/lib/python2.7/dist-packages/django/test/client.py", line
380, in generic
  return self.request(**r)
File "/usr/lib/python2.7/dist-packages/django/test/client.py", line
467, in request
  six.reraise(*exc_info)
File
"/usr/lib/python2.7/dist-packages/django/core/handlers/base.py",
line 149, in get_response
  response = self.process_exception_by_middleware(e, request)
File
"/usr/lib/python2.7/dist-packages/django/core/handlers/base.py",
line 147, in get_response
  response = wrapped_callback(request, *callback_args,
  **callback_kwargs)
File
"/usr/lib/python2.7/dist-packages/django/contrib/auth/decorators.py",
line 23, in _wrapped_view
  return view_func(request, *args, **kwargs)
File

"/home/lamby/temp/cdt.20151207215322.HOuGTibadH/python-django-openstack-auth-2.0.0/openstack_auth/views.py",
line 229, in switch
  redirect_to = request.REQUEST.get(redirect_field_name, '')
  AttributeError: 'WSGIRequest' object has no attribute 'REQUEST'
  
  --
  Ran 44 tests in 0.466s
  
  FAILED (errors=10)
  Creating test database for alias 'default'...
  Destroying test database for alias 'default'...
  debian/rules:26: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 10
  make[1]: Leaving directory
  
'/home/lamby/temp/cdt.20151207215322.HOuGTibadH/python-django-openstack-auth-2.0.0'
  debian/rules:12: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


python-django-openstack-auth.2.0.0-3.unstable.amd64.log.txt.gz
Description: Binary data

Bug#806904: [pkg-gnupg-maint] Bug#806904: Please document how to switch to gpg2

[Daniel Kahn Gillmor]

Hi Guido--

On Wed 2015-12-02 12:48:04 -0500, Guido Günther wrote:
> I wanted to use gpg2 for "everything" like signing git tags, etc. Since
> these tools still invoke gpg directly I checked /etc/alternatives/gpg
> but did not find any so I went for:
>
> cat < #!/bin/bash
>
> exec gpg2 "$*"
>
> in the path to invoke gpg2 instead of gpg Is that the recommended
> procedure in Debian atm or did I miss docs on that? I checked
>
> man gpg2
>
> and /usr/share/doc/gnupg2/README.Debian but did not find any pointers on
> this issue.

the right way to do this is for the packages to do it for you.  the
gnupg2 package will at some point (hopefully soon) provide /usr/bin/gpg,
and the 1.4 branch will become /usr/bin/gpg1.  This was discussed at
Debconf this summer, but hasn't been completed yet.  Expect to see it in
experimental before it hits unstable, though ;)

I'm reluctant to officially document "how to switch to gpg2" before that
because i don't want to have lots of people doing it in ways that will
cause breakage once the packages transition directly.

  --dkg

Bug#807345: redmine: CVE-2015-8473: Issues API may disclose changeset messages that are not visible

[Salvatore Bonaccorso]

Source: redmine
Version: 3.0~20140825-5
Severity: important
Tags: security upstream patch fixed-upstream
Forwarded: https://www.redmine.org/issues/21136

Hi,

the following vulnerability was published for redmine.

CVE-2015-8473[0]:
Issues API may disclose changeset messages that are not visible

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-2015-8473
[1] https://www.redmine.org/issues/21136

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#770135: Bug also present in systemd 215-17+deb8u2

[Alistair Turnbull]

I too am seeing 25 second delays when I log in by ssh. I can turn 
the problem on and off exactly as described in #86:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770135#86

When the problem is "on", many things are broken in addition to slow ssh 
login. The "shutdown" and "reboot" commands do nothing. Starting and 
stopping services fails with a timeout. The latter in turn often breaks 
"apt-get upgrade".


Sometimes the problem turns "on" when the server has been up for a long 
time. I don't know what event triggers it.


Alistair

Bug#807249: needs versioned build dependency on python3-setuptools-scm

[Gianfranco Costamagna]

Control: tags -1 pending

Hi dear Marc and Thomas,

(Thomas I'm ccing you, only for the python-msgpack backport request, at the 
bottom of the mail)

I honestly don't follow too much your approach :)

You called yourself out from the team, but you try to contribute anyway...
what about joining it again :D ?

and now the specific answer:


>setup.py demends python3-setuptool-scm >= 1.7, which is not satisfied
>in Debian jessie.


it isn't satisfied even a lower version AFAIK (however it might be not true for 
people apt-pinning stuff
and not updating it)

>To make life less of python hell for backporters, please also declare
>this versioned dependencies in debian/control so that one doesn't
>spend hours guessing why package build fails.


while this is true in general, it doesn't change too much in this particular
context. 1.7 is not part of any stable/testing/unstable Debian distribution, and
(since upstream asked this a while ago), I personally built&signed&uploaded 
setuptools-scm
for jessie backports (version 1.8)

now the only package missing is python-msgpack, and zigo is already aware of 
the issue (and the backport request)

I committed the change, because it is harmless, but I don't think about any
useful use case where it might change anything.

It will be part of the next upload (coming in the next few days), and as soon 
as msgpack is available we will be able to
backport it to jessie.

cheers,

G.