Bug#810225: apt: incorrect message about automatically installed packages

[Vincent Lefevre]

Control: found -1 1.3.1

After purging the nvidia packages for a clean reinstallation:

# apt install nvidia-kernel-dkms nvidia-settings
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libegl-nvidia0 libegl-nvidia0:i386 libegl1-glvnd-nvidia
  libegl1-glvnd-nvidia:i386 libgl1-glvnd-nvidia-glx:i386 libgldispatch0-nvidia
  libgldispatch0-nvidia:i386 libgles-nvidia1 libgles-nvidia1:i386
  libgles-nvidia2 libgles-nvidia2:i386 libgles1-glvnd-nvidia
  libgles1-glvnd-nvidia:i386 libgles2-glvnd-nvidia libgles2-glvnd-nvidia:i386
  libglx-nvidia0 libglx-nvidia0:i386 libglx0-glvnd-nvidia
  libglx0-glvnd-nvidia:i386 libnvidia-cfg1 libnvidia-cfg1:i386
  libnvidia-eglcore libnvidia-eglcore:i386 libnvidia-glcore:i386 libnvidia-ml1
  libopengl0-glvnd-nvidia libopengl0-glvnd-nvidia:i386 libvulkan1
  libvulkan1:i386 linux-doc-4.6 linux-image-4.5.0-2-amd64
  linux-image-4.6.0-1-amd64 nvidia-driver-bin nvidia-driver-libs:i386
  nvidia-driver-libs-i386:i386 nvidia-persistenced nvidia-vulkan-common
  nvidia-vulkan-icd nvidia-vulkan-icd:i386
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  glx-alternative-nvidia libnvidia-glcore libxnvctrl0 nvidia-alternative
  nvidia-kernel-common nvidia-kernel-support nvidia-legacy-check
  nvidia-modprobe nvidia-support nvidia-vdpau-driver xserver-xorg-video-nvidia
Suggested packages:
  nvidia-driver
Recommended packages:
  nvidia-driver | libcuda1 libgl1-nvidia-glx nvidia-driver nvidia-settings
The following NEW packages will be installed:
  glx-alternative-nvidia libnvidia-glcore libxnvctrl0 nvidia-alternative
  nvidia-kernel-common nvidia-kernel-dkms nvidia-kernel-support
  nvidia-legacy-check nvidia-modprobe nvidia-settings nvidia-support
  nvidia-vdpau-driver xserver-xorg-video-nvidia
0 upgraded, 13 newly installed, 0 to remove and 278 not upgraded.
Need to get 0 B/17.9 MB of archives.
After this operation, 77.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

while I have only one nvidia package installed:

cventin:~> dpkg -l | grep nvidia
ii  nvidia-installer-cleanup   20151021+4   
amd64cleanup after driver installation with the nvidia-installer

If I omit the nvidia-settings package:

# apt install nvidia-kernel-dkms
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-doc-4.6 linux-image-4.5.0-2-amd64 linux-image-4.6.0-1-amd64
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  glx-alternative-nvidia libegl-nvidia0 libegl-nvidia0:i386
  libegl1-glvnd-nvidia libegl1-glvnd-nvidia:i386 libgl1-glvnd-nvidia-glx
  libgl1-glvnd-nvidia-glx:i386 libgldispatch0-nvidia
  libgldispatch0-nvidia:i386 libgles-nvidia1 libgles-nvidia1:i386
  libgles-nvidia2 libgles-nvidia2:i386 libgles1-glvnd-nvidia
  libgles1-glvnd-nvidia:i386 libgles2-glvnd-nvidia libgles2-glvnd-nvidia:i386
  libglx-nvidia0 libglx-nvidia0:i386 libglx0-glvnd-nvidia
  libglx0-glvnd-nvidia:i386 libnvidia-cfg1 libnvidia-cfg1:i386
  libnvidia-eglcore libnvidia-eglcore:i386 libnvidia-glcore
  libnvidia-glcore:i386 libnvidia-ml1 libopengl0-glvnd-nvidia
  libopengl0-glvnd-nvidia:i386 libvulkan1 libvulkan1:i386 nvidia-alternative
  nvidia-driver nvidia-driver-bin nvidia-driver-libs nvidia-driver-libs:i386
  nvidia-driver-libs-i386:i386 nvidia-kernel-common nvidia-kernel-support
  nvidia-legacy-check nvidia-modprobe nvidia-persistenced nvidia-support
  nvidia-vdpau-driver nvidia-vulkan-common nvidia-vulkan-icd
  nvidia-vulkan-icd:i386 xserver-xorg-video-nvidia
Suggested packages:
  vulkan-utils vulkan-utils:i386
Recommended packages:
  nvidia-settings
The following NEW packages will be installed:
  glx-alternative-nvidia libegl-nvidia0 libegl-nvidia0:i386
  libegl1-glvnd-nvidia libegl1-glvnd-nvidia:i386 libgl1-glvnd-nvidia-glx
  libgl1-glvnd-nvidia-glx:i386 libgldispatch0-nvidia
  libgldispatch0-nvidia:i386 libgles-nvidia1 libgles-nvidia1:i386
  libgles-nvidia2 libgles-nvidia2:i386 libgles1-glvnd-nvidia
  libgles1-glvnd-nvidia:i386 libgles2-glvnd-nvidia libgles2-glvnd-nvidia:i386
  libglx-nvidia0 libglx-nvidia0:i386 libglx0-glvnd-nvidia
  libglx0-glvnd-nvidia:i386 libnvidia-cfg1 libnvidia-cfg1:i386
  libnvidia-eglcore libnvidia-eglcore:i386 libnvidia-glcore
  libnvidia-glcore:i386 libnvidia-ml1 libopengl0-glvnd-nvidia
  libopengl0-glvnd-nvidia:i386 libvulkan1 libvulkan1:i386 nvidia-alternative
  nvidia-driver nvidia-driver-bin nvidia-driver-libs nvidia-driver-libs:i386
  nvidia-driver-libs-i386:i386 nvidia-kernel-common nvidia-kernel-dkms
  nvidia-kernel-support nvidia-legacy-check nvidia-modprobe
  nvidia-persistenced nvidia-support nvidia-vdpau-driver nvidia-vulkan-common
  nvidia-vulkan-icd nvidia-vulkan-icd:i386 xserver-xorg-video-n

Bug#844608: [Pkg-protobuf-devel] Looking for sponsor for protobuf NMU

[GCS]

Hi Lumin,

I don't think a Cc is needed, all of us (should be) subscribed to this
mailing list.

On Tue, Nov 22, 2016 at 5:32 AM, lumin  wrote:
> I prepared an NMU for protobuf for adding
> python3-protobuf binary package, and now
> I'm asking for maintainer comments and
> looking for sponsor.
 I'll check it if I get home - if no one objects against the Python3
variant of ProtoBuf.

Regards,
Laszlo/GCS

Bug#844361: Regarding to the windows crush...

[Peter Xu]

Hi, Michael, Maciej,

Sorry to respond late. Thanks for the help in verifying the issue.
I'll post a patch upstream without that warning line.

(I think I have problem receiving notifications from the bug system,
 though that's another story...)

Thanks,

-- peterx

Bug#845297: [www.debian.org] Website transition from CVS to Git

[Laura Arjona Reina]

Package: www.debian.org
Severity: normal

Debian's website structure is currently still kept in CVS.
We have discussed several times about migrating to another VCS.

Overview of the options and checklist is in

https://wiki.debian.org/WebsiteGitTransition

If you work on any of the steps mentioned there (or other approach),
please send your patches against this bug report.

Any help is welcome!

Cheers

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#845295: [debian-mysql] Bug#845295: mariadb-server-10.0: timeout at startup

[Otto Kekäläinen]

Hello!

What does the syslog or other logs say, what was the real reason
MariaDB failed to start?

Bug#845296: tzdata: Asia/Istanbul offset incorrect

[Douglas R Colkitt]

Package: tzdata
Version: 2016f-0+deb8u1
Severity: important
Tags: l10n



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

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

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.56

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information:
  tzdata/Zones/SystemV:
  tzdata/Zones/Pacific:
  tzdata/Zones/Antarctica:
  tzdata/Zones/Asia: Istanbul
* tzdata/Areas: Asia
  tzdata/Zones/Atlantic:
  tzdata/Zones/Indian:
* tzdata/Zones/Etc: GMT+0
  tzdata/Zones/Arctic:
  tzdata/Zones/Africa:
  tzdata/Zones/Australia:
  tzdata/Zones/Europe:
  tzdata/Zones/America: New_York
  tzdata/Zones/US:

Bug#845295: mariadb-server-10.0: timeout at startup

[duck]

Package: mariadb-server-10.0
Version: 10.0.28-0+deb8u1

Quack,

After a reboot I found Mariadb stopped with the following logs:

Nov 22 07:52:15 Toushirou mysql[1202]: Starting MariaDB database server: 
mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
failed!
Nov 22 07:52:15 Toushirou systemd[1]: mysql.service: control process 
exited, code=exited status=1
Nov 22 07:52:15 Toushirou systemd[1]: Failed to start LSB: Start and 
stop the mysql database server daemon.
Nov 22 07:52:15 Toushirou systemd[1]: Unit mysql.service entered failed 
state.
Nov 22 07:52:23 Toushirou mysqld[2860]: 161122  7:52:23 [Note] 
/usr/sbin/mysqld: ready for connections.
Nov 22 07:52:23 Toushirou mysqld[2860]: Version: 
'10.0.28-MariaDB-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 
3306  (Debian)


So it seems it took a bit more time than expected and was then 
considered a failure. Problem is the systemd status is wrong, so it can 
impact starting up other services.


I guess the solution would be to implement the systemd service 
configuration, but in the meanwhile you could consider increasing a bit 
the timeout.


Regards.
\_o<

--
Marc Dequènes

Bug#844803: 844803 FTBFS: build-dependency not installable: libssl-dev

[Lucas Nussbaum]

On 21/11/16 at 16:25 +0100, Christoph Martin wrote:
> Hi Lucas,
> 
> please retry the build. Why should libssl-dev be not installable?
> 
> I can't see the problem in libapache2-mod-auth-openidc

As written in the bug report, builds are retried automatically once to
exclude random errors. Did you try to build it? Because it still fails,
so I'm surprised that you can't see the problem.
dose reports the following:

(I)Distcheck: Cudf Universe: 53096 packages
(I)Distcheck: --checkonly specified, consider all packages as background 
packages
(I)Distcheck: Solving...
output-version: 1.2
native-architecture: amd64
report:
 -
  package: sbuild-build-depends-libapache2-mod-auth-openidc-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
conflict:
 pkg1:
  package: libssl1.0-dev
  version: 1.0.2j-4
  architecture: amd64
  unsat-conflict: libssl-dev:amd64
 pkg2:
  package: libssl-dev
  version: 1.1.0c-2
  architecture: amd64
 depchain1:
  -
   depchain:
-
 package: sbuild-build-depends-libapache2-mod-auth-openidc-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: apache2-dev:amd64
-
 package: apache2-dev
 version: 2.4.23-7
 architecture: amd64
 depends: libssl1.0-dev:amd64 | libssl-dev:amd64 (< 1.1)
 depchain2:
  -
   depchain:
-
 package: sbuild-build-depends-libapache2-mod-auth-openidc-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: libssl-dev:amd64
 
background-packages: 53095
foreground-packages: 1
total-packages: 53096

Lucas

Bug#845293: ITP: node-mimic-fn -- Make a function mimic another one

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-mimic-fn
  Version : 1.1.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/mimic-fn#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Make a function mimic another one



signature.asc
Description: OpenPGP digital signature

Bug#836266: dirmngr: Please disable "use-tor" by default.

[Gabriel Filion]

Hi there,

For what it's worth I've been experiencing the same issue up to now:
impossible to search or get keys with "use-tor" enabled, which was
forced into the config file seemingly by parcimonie.

However it's just been resolved by an upgrade of gnupg/dirmngr to the
latest version in sid, 2.1.16-2.

I believe the fix to use-tor issues was added in 2.1.15-9 by using adns
for better DNS resolution.



signature.asc
Description: OpenPGP digital signature

Bug#836395: libopencc2: missing files cause librime fail to work

[Boyuan Yang]

Control: severty -1 grave
Control: affects -1 librime
Control: affects -1 ibus-rime
Control: affects -1 fcitx-rime
Control: tags -1 + patch

Sorry, but I think we need to raise the severty to RC since the missing files 
are generally making this tool unusable.

Fix is really easy. Perhaps all we need to do is to add the following lines 
into debian/copyright:

diff --git a/debian/copyright b/debian/copyright
index b9a229c..1f4e4e2 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -74,6 +75,12 @@ License: Expat
 Files: deps/darts-clone/*
 Copyright: 2001-2008, Taku Kudoh 
 License: BSD-3-Clause
+
+Files: deps/gtest-1.7.0/*
+Copyright: 2008, Google Inc.
+License: BSD-3-Clause
+
+License: BSD-3-Clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:


Sincerely,
Boyuan Yang

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

Bug#845294: ITP: node-lcid -- Mapping between standard locale identifiers and Windows locale identifiers (LCID)

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-lcid
  Version : 1.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/lcid
* License : Expat
  Programming Lang: JavaScript
  Description : Mapping between standard locale identifiers and
Windows locale identifiers (LCID)



signature.asc
Description: OpenPGP digital signature

Bug#845278:

[Adrian Bunk]

On Tue, Nov 22, 2016 at 12:01:16AM -0500, Paul R. Tagliamonte wrote:
> Yeah, same here on a sid system:
> 
> Preparing to unpack .../libxtables12_1.6.0+snapshot20161117-2_amd64.deb ...
> Unpacking libxtables12:amd64 (1.6.0+snapshot20161117-2) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libxtables12_1.6.0+snapshot20161117-2_amd64.deb
> (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libxtables.so.12.0.0',
> which is also in package libxtables11:amd64 1.6.0+snapshot20161117-1
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/libxtables12_1.6.0+snapshot20161117-2_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> However, the old package wasn't used anymore, so a dpkg --purge
> libxtables11:amd64, and an apt-get install -f did the trick.
> 
> Seems like a Conflicts/Breaks might be best here, apt can just get rid
> of the other package.

Breaks+Replaces is the proper solution.

>   Paul

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#845292: ITP: node-require-directory -- Recursively require files in a directory

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-require-directory
  Version : 2.1.1
  Upstream Author : Troy Goode 
(http://github.com/troygoode/)
* URL : https://github.com/troygoode/node-require-directory/
* License : Expat
  Programming Lang: JavaScript
  Description : Recursively iterates over specified directory,
require()'ing each file, and returning a nested hash structure
containing those modules.




signature.asc
Description: OpenPGP digital signature

Bug#845291: bouncycastle: versioned paths refer to version 1.51 instead of 1.55

[tony mancill]

Source: bouncycastle
Version: 1.55-1
Severity: minor

Hi Team:

Reporting here in case anyone else runs into it.  It's not really a
problem, but potentially of confusing.  I'll try to fix it in the next
few days.  All of the versioned paths for the BC 1.55-1 binary
packages refer to version 1.51.  For example:

$ dpkg -s libbcprov-java
Package: libbcprov-java
Status: install ok installed
Priority: optional
Section: java
Installed-Size: 3128
Maintainer: Debian Java Maintainers 

Architecture: all
Source: bouncycastle
Version: 1.55-1
...


$ dpkg -L libbcprov-java | grep 1.5
/usr/share/java/bcprov-1.51.jar
/usr/share/maven-repo/org/bouncycastle/bcprov/1.51
/usr/share/maven-repo/org/bouncycastle/bcprov/1.51/bcprov-1.51.pom
/usr/share/maven-repo/org/bouncycastle/bcprov/1.51/bcprov-1.51.jar

Cheers,
tony

Bug#845223: 0ad: Crashes on startup with cache.cpp(43): Assertion failed: "cache.Validate()"

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible

Hi,

On Mon, Nov 21, 2016 at 8:35 AM,   wrote:
> Package: 0ad
> Version: 0.0.21-2
>
> Hiya,
>
> I just installed 0ad on my system.
> It crashes as soon as I start the game.
> See attachment for crash log. If I say "go on", it manages to play the
> music.
>
> note: I thought there was a -dbg package, but not in my repos.

0ad has now migrated to using auto-generated dbgsym packages (like
many other packages in Debian sid). You'll have to add an additional
line to your sources.list to pick up the dbgsym repository [1].

Please file a bug report upstream after obtaining a backtrace at [2].

Regards,
Vincent

[1] https://lists.debian.org/debian-devel/2015/12/msg00262.html
[2] http://trac.wildfiregames.com/newticket

Bug#634262: arpwatch-ng status

[Afif Elghraoui]

Hi, Florian,

على الإثنين 21 تشرين الثاني 2016 ‫01:22، كتب Florian Schlichting:
> in 2014 when I created the Debian git repo, I also created an
> 'upstream-ng' branch so I (or someone else - I never got to it) could
> step through the development of arpwatch-ng in a little more detail and
> decide if that's a better upstream to base the Debian package on. You
> can still find that branch on github:
> 
> https://github.com/fschlich/Debian-arpwatch/commits/upstream-ng
> 
> Feel free to make use of any of it and push it to the git.d.o repo's
> upstream branch if you see fit - I'm glad if it's of use to anybody!
> 
>> > *  redirects to
>> > , and freecode is frozen since
>> > 2014[1]. It looks like the only way to contact upstream is to see
>> > whether freecode site support can help.
>> > 
>> > ...or fork the project again.
> I think the arpwatch-ng upstream is as dead as the arpwatch one. There
> are a few more repos and patches on github, but it doesn't look like
> anybody has stepped up to pick up the pieces. Still I think arpwatch
> continues to be useful, and if you find the time to look into the
> arpwatch-ng work and find it to be sensible, please go forth and upload
> a Debian package based on it!

Thanks for the information, but my interest in arpwatch was short-lived,
so I don't expect to be working on it. Your update might spark someone
else's interest, though, and it's good that it's now documented here.

Thanks and regards
Afif

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

Bug#845286: O: libemu -- x86 shellcode detection and emulation

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of libemu, David Martínez Moreno ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libemu
Binary: libemu-dev, libemu2, python-libemu
Version: 0.2.0+git20120122-1.2
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>= 9), autoconf, automake, libtool, check, 
python-all-dev (>= 2.3.5-11)
Architecture: any
Standards-Version: 3.9.3
Format: 3.0 (quilt)
Files:
 fad9ac7fd24866b8e8056c1fa772c78e 1294 libemu_0.2.0+git20120122-1.2.dsc
 3ced2457994f4c52dd2d687434e7cd1d 561840 libemu_0.2.0+git20120122.orig.tar.gz
 eb7ff9aafaf7107e6d85a960cbefa50c 4969 
libemu_0.2.0+git20120122-1.2.debian.tar.gz
Checksums-Sha1:
 2084f5722591c32261bd8e5ac36349bd3ecdd91b 1294 libemu_0.2.0+git20120122-1.2.dsc
 3e5a87a1c5c27e8b6cce5e55fb45eab8bb100408 561840 
libemu_0.2.0+git20120122.orig.tar.gz
 51f77606770161c9b60ecdfac082870eddfae240 4969 
libemu_0.2.0+git20120122-1.2.debian.tar.gz
Checksums-Sha256:
 d91da679e88af9743ccb2890acab6538eaeeef623a868ad41e12442da8dc8abc 1294 
libemu_0.2.0+git20120122-1.2.dsc
 7b90e40cd6286a1cd93acddb1c5984e8f5bf7168b630d21f276d48d8219e2f16 561840 
libemu_0.2.0+git20120122.orig.tar.gz
 5a214c95510c2b41430d054c225df89782e193ef3144685caabc71f10cd250a8 4969 
libemu_0.2.0+git20120122-1.2.debian.tar.gz
Homepage: http://libemu.carnivore.it/
Package-List: 
 libemu-dev deb libdevel extra
 libemu2 deb libs extra
 python-libemu deb python extra
Directory: pool/main/libe/libemu
Priority: source
Section: misc

Package: libemu
Binary: libemu-dev, libemu2, python-libemu
Version: 0.2.0+git20120122-1.2
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>= 9), autoconf, automake, libtool, check, 
python-all-dev (>= 2.3.5-11)
Architecture: any
Standards-Version: 3.9.3
Format: 3.0 (quilt)
Files:
 fad9ac7fd24866b8e8056c1fa772c78e 1294 libemu_0.2.0+git20120122-1.2.dsc
 3ced2457994f4c52dd2d687434e7cd1d 561840 libemu_0.2.0+git20120122.orig.tar.gz
 eb7ff9aafaf7107e6d85a960cbefa50c 4969 
libemu_0.2.0+git20120122-1.2.debian.tar.gz
Checksums-Sha256:
 d91da679e88af9743ccb2890acab6538eaeeef623a868ad41e12442da8dc8abc 1294 
libemu_0.2.0+git20120122-1.2.dsc
 7b90e40cd6286a1cd93acddb1c5984e8f5bf7168b630d21f276d48d8219e2f16 561840 
libemu_0.2.0+git20120122.orig.tar.gz
 5a214c95510c2b41430d054c225df89782e193ef3144685caabc71f10cd250a8 4969 
libemu_0.2.0+git20120122-1.2.debian.tar.gz
Homepage: http://libemu.carnivore.it/
Package-List: 
 libemu-dev deb libdevel extra
 libemu2 deb libs extra
 python-libemu deb python extra
Directory: pool/main/libe/libemu
Priority: source
Section: misc

Package: libemu-dev
Source: libemu
Version: 0.2.0+git20120122-1.2
Installed-Size: 1902
Maintainer: David Martínez Moreno 
Architecture: amd64
Depends: libemu2 (= 0.2.0+git20120122-1.2)
Description-en: x86 shellcode detection and emulation
 libemu is a small library written in C offering basic x86 emulation and
 shellcode detection using GetPC heuristics.  Intended use is within network
 intrusion/prevention detections and honeypots.
 .
 libemu supports:
   * executing x86 instructions
 * reading x86 binary code
 * register emulation
 * basic FPU emulation
   * shellcode execution
 * shellcode detection
   * using GetPC heuristics
   * static analysis
   * and binary backwards traversal
  * Win32 API hooking
 .
 Using libemu one can:
   * detect shellcodes
   * execute the shellcodes
   * profile shellcode behaviour
 .
 This package has the development files.
Description-md5: e68b2936252f19f5b945e8d2fc0dfb33
Homepage: http://libemu.carnivore.it/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: extra
Filename: pool/main/libe/libemu/libemu-dev_0.2.0+git20120122-1.2_amd64.deb
Size: 395680
MD5sum: 67f02a129422d39b9a589958f8598b42
SHA1: 14bef6a2a43e1ca41453c29f275307197851fa21
SHA256: 4ceba08c770e8097e1e6915d12b503736da8b8adde336370fa0daf542001619f

Package: libemu2
Source: libemu
Version: 0.2.0+git20120122-1.2
Installed-Size: 1246
Maintainer: David Martínez Moreno 
Architecture: amd64
Depends: libc6 (>= 2.15)
Description-en: x86 shellcode detection and emulation
 libemu is a small library written in C offering basic x86 emulation and
 shellcode detection using GetPC heuristics.  Intended use is within network
 intrusion/prevention detections and honeypots.
 .
 libemu supports:
   * executing x86 instructions
 * reading x86 binary code
 * register emulation
 * basic FPU emulation
   * shellcode execution
 * shellcode detection
   * using GetPC heuristics
   * static analysis
   * and binary backwards traversal
  * Win32 API hooking
 .
 Using libemu one 

Bug#845287: O: uclmmbase -- UCL Common Code (Multimedia) Library - development

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of uclmmbase, David Martínez Moreno ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: uclmmbase
Binary: libuclmmbase1-dev, libuclmmbase1
Version: 1.2.16.0-1
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>= 4.0.16), gtk-doc-tools
Architecture: any
Standards-Version: 3.6.2.2
Format: 1.0
Files:
 9fc6752fcc3b51c4b30827ab63ecfa91 628 uclmmbase_1.2.16.0-1.dsc
 2e547c581d6dca7f48a08bc1530fc39b 217732 uclmmbase_1.2.16.0.orig.tar.gz
 bc9c988dd7582a9fa6122b6c4ad7e445 32947 uclmmbase_1.2.16.0-1.diff.gz
Checksums-Sha1:
 321e34717a6d5f010c4e63cb2bde89236b3f2e54 628 uclmmbase_1.2.16.0-1.dsc
 47168a03a4c9280fa9b7fa453a0be5a60e3cce2d 32947 uclmmbase_1.2.16.0-1.diff.gz
 3783430f2ffd9b9038ab092a2dd09b3c9e7e6ac6 217732 uclmmbase_1.2.16.0.orig.tar.gz
Checksums-Sha256:
 7104565e327f8360f307ef5fa6ee3a2d1d7803dab59777f91ff0210dbce39ed9 628 
uclmmbase_1.2.16.0-1.dsc
 503b84794834ca2919ab5d61117f0538ae16e9d638980e427d29f1c1f6449ffc 32947 
uclmmbase_1.2.16.0-1.diff.gz
 ab78a85652d69c7bd6513acfdca5a739a28db947871ef1649ae5ac0a843c347e 217732 
uclmmbase_1.2.16.0.orig.tar.gz
Directory: pool/main/u/uclmmbase
Priority: source
Section: libs

Package: uclmmbase
Binary: libuclmmbase1-dev, libuclmmbase1
Version: 1.2.16.0-1
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>= 4.0.16), gtk-doc-tools
Architecture: any
Standards-Version: 3.6.2.2
Format: 1.0
Files:
 9fc6752fcc3b51c4b30827ab63ecfa91 628 uclmmbase_1.2.16.0-1.dsc
 2e547c581d6dca7f48a08bc1530fc39b 217732 uclmmbase_1.2.16.0.orig.tar.gz
 bc9c988dd7582a9fa6122b6c4ad7e445 32947 uclmmbase_1.2.16.0-1.diff.gz
Checksums-Sha256:
 7104565e327f8360f307ef5fa6ee3a2d1d7803dab59777f91ff0210dbce39ed9 628 
uclmmbase_1.2.16.0-1.dsc
 503b84794834ca2919ab5d61117f0538ae16e9d638980e427d29f1c1f6449ffc 32947 
uclmmbase_1.2.16.0-1.diff.gz
 ab78a85652d69c7bd6513acfdca5a739a28db947871ef1649ae5ac0a843c347e 217732 
uclmmbase_1.2.16.0.orig.tar.gz
Directory: pool/main/u/uclmmbase
Priority: source
Section: libs

Package: libuclmmbase1-dev
Source: uclmmbase
Version: 1.2.16.0-1
Installed-Size: 636
Maintainer: David Martínez Moreno 
Architecture: amd64
Replaces: libmbonecommon-dev, libucl-common-dev
Provides: libuclmmbase-dev, libmbonecommon-dev, libucl-common-dev
Depends: libuclmmbase1 (= 1.2.16.0-1), libc6-dev
Conflicts: libuclmmbase-dev, libumbonecommon-dev, libucl-common-dev
Description-en: UCL Common Code (Multimedia) Library - development
 Routines common to a number of multimedia tools. This library is required
 to build RAT v3.2.7 or later, SDR, and may be needed for other UCL tools.
 .
 Header files and static library.
Description-md5: e7c397708870e715cca46e26a153ba84
Tag: culture::czech, devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/u/uclmmbase/libuclmmbase1-dev_1.2.16.0-1_amd64.deb
Size: 138922
MD5sum: 9cdf9bb4391c48f3f5748c5c933204d0
SHA1: 9251849caf7fbc6316f93bc0205be03b503251c8
SHA256: e5f1770b8a80e4746441d828edc3a0deb77a5cf13ad60bce645cb908bf1621a3

Package: libuclmmbase1
Source: uclmmbase
Version: 1.2.16.0-1
Installed-Size: 196
Maintainer: David Martínez Moreno 
Architecture: amd64
Replaces: libmbonecommon, libucl-common
Provides: libuclmmbase, libmbonecommon, libucl-common
Depends: libc6 (>= 2.3.5-1)
Conflicts: libuclmmbase, libmbonecommon, libucl-common
Description-en: UCL Common Code (Multimedia) Library
 Routines common to a number of multimedia tools. This library is required
 to build RAT v3.2.7 or later, SDR, and may be needed for other UCL tools.
 .
 Shared library.
Description-md5: 3b317b250bf8af1bdca4e62b2255c194
Tag: devel::library, role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/u/uclmmbase/libuclmmbase1_1.2.16.0-1_amd64.deb
Size: 79954
MD5sum: 427e7d8e1a38a16d0160bb66fa021376
SHA1: 6351a1f69c5d627ec4c9f707e9a1d7a3f0bb1330
SHA256: d30bfb29e9e1b25bd9618425db7b3bfac9219dd317d396955f25b91517642189

Package: libuclmmbase1-dev
Source: uclmmbase
Version: 1.2.16.0-1
Installed-Size: 636
Maintainer: David Martínez Moreno 
Architecture: amd64
Replaces: libmbonecommon-dev, libucl-common-dev
Provides: libuclmmbase-dev, libmbonecommon-dev, libucl-common-dev
Depends: libuclmmbase1 (= 1.2.16.0-1), libc6-dev
Conflicts: libuclmmbase-dev, libumbonecommon-dev, libucl-common-dev
Description-en: UCL Common Code (Multimedia) Library - development
 Routines common to a number of multimedia tools. This library is required
 to build RAT v3.2.7 or later, SDR, and may be needed for other UCL tools.
 .
 Header files and static library.
Description-md5: e7c397708870e715cca46e26a153ba84
Tag: culture::czech, dev

Bug#845284: O: pius -- utilities for signing GPG UIDs and prepare a signing party

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of pius David Martínez Moreno ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: pius
Binary: pius
Version: 2.0.11-1
Maintainer: Luke Cycon 
Uploaders: David Martínez Moreno 
Build-Depends: debhelper (>= 9.0.0), python | python-all | python-dev | 
python-all-dev
Architecture: all
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 745213153a4bafa58ccf62f06edb4ff4 1242 pius_2.0.11-1.dsc
 7e3229b493570f5d97cc349919f071df 31351 pius_2.0.11.orig.tar.bz2
 e358d8e012be119e4be958173044afd7 4652 pius_2.0.11-1.debian.tar.xz
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/pius.git
Vcs-Git: git://anonscm.debian.org/collab-maint/pius.git
Checksums-Sha1:
 4d9e527a29a6e89f0abb58adb9102dcfe927423a 1242 pius_2.0.11-1.dsc
 0c9b74f271bf195d8636d8406fbb56cc024195ad 31351 pius_2.0.11.orig.tar.bz2
 e6836443c0298455b1765349472a327c9dc14dc7 4652 pius_2.0.11-1.debian.tar.xz
Checksums-Sha256:
 2eaf353e4c790ffec566a3a2dd1f4e03356eed9e661ff3a90bc3469f843f0afa 1242 
pius_2.0.11-1.dsc
 aeb8ef25fb59074532e380e70c71d1f5d6c9fcd13aa0cf040a7581693ef6ab5d 31351 
pius_2.0.11.orig.tar.bz2
 e1bfc2522dad0b36267077b977983a44216e718200f7f28da13d40c7c4d25b58 4652 
pius_2.0.11-1.debian.tar.xz
Homepage: http://www.phildev.net/pius/
Package-List: 
 pius deb python extra
Directory: pool/main/p/pius
Priority: source
Section: python

Package: pius
Binary: pius
Version: 2.2.1-2
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>= 9.0.0), python | python-all | python-dev | 
python-all-dev, dh-python
Architecture: all
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 7a68e2df87e532977e92c59ba5dd6118 1852 pius_2.2.1-2.dsc
 9e3cb58a6e3576602bc39943818791f1 39466 pius_2.2.1.orig.tar.bz2
 4d2a27224e8aec8946a0423d74464024 12112 pius_2.2.1-2.debian.tar.xz
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/pius.git
Vcs-Git: git://anonscm.debian.org/collab-maint/pius.git
Checksums-Sha256:
 0ef97f3332c08d1e7da9d2a2a6ee7cc40f1bfb0fe5636b85c47b58eb4816929d 1852 
pius_2.2.1-2.dsc
 82b842b13237a40a8c4e767e06aae419e93c0024f1dd9f30e287015cd5e56d00 39466 
pius_2.2.1.orig.tar.bz2
 4f4b06a18f830a3958b3fb5e6a882be76dca9b17fdfd47f2a62a33aad25ae543 12112 
pius_2.2.1-2.debian.tar.xz
Homepage: http://www.phildev.net/pius/
Package-List: 
 pius deb utils extra arch=all
Directory: pool/main/p/pius
Priority: source
Section: python

Package: pius
Version: 2.2.1-2
Installed-Size: 149
Maintainer: David Martínez Moreno 
Architecture: all
Depends: python, gnupg, gnupg2, python:any (<< 2.8), python:any (>= 2.7.5-5~)
Description-en: utilities for signing GPG UIDs and prepare a signing party
 The PGP Individual UID Signer (PIUS) is a set of tools for individually
 signing all of the UIDs on a set of keys and encrypt-emailing each
 one to its respective email address. This drastically reduces the time
 and errors involved in signing keys after a keysigning party.
Description-md5: 4e9f07f85ae02bb13250aaffc9c0c695
Homepage: http://www.phildev.net/pius/
Tag: implemented-in::python, role::program, security::cryptography
Section: python
Priority: extra
Filename: pool/main/p/pius/pius_2.2.1-2_all.deb
Size: 41034
MD5sum: f3109133c8b411311f990a6b5885c0a6
SHA256: 3f7f84e5d25ea001fb47ec7eae99be89d4fb01ed32b270810ab93664031bef85

Package: pius
Version: 2.0.11-1
Installed-Size: 90
Maintainer: Luke Cycon 
Architecture: all
Depends: python, gnupg
Description-en: utilities for signing GPG UIDs and prepare a signing party
 The PGP Individual UID Signer (PIUS) is a set of tools for individually
 signing all of the UIDs on a set of keys and encrypt-emailing each
 one to its respective email address. This drastically reduces the time
 and errors involved in signing keys after a keysigning party.
Description-md5: 4e9f07f85ae02bb13250aaffc9c0c695
Homepage: http://www.phildev.net/pius/
Tag: implemented-in::python, role::program, security::cryptography
Section: python
Priority: extra
Filename: pool/main/p/pius/pius_2.0.11-1_all.deb
Size: 31240
MD5sum: f7833afd5a65e777b25f03cc1270b514
SHA1: cc65ad1fb6c48307ca0607ce36ff0eb18ab3cf8a
SHA256: 22a344ad378afd4b4d1008cad78fd6457a213030e15f9cbe84cca7e0d2db1bb5

Package: pius
Version: 2.2.1-2
Installed-Size: 149
Maintainer: David Martínez Moreno 
Architecture: all
Depends: python, gnupg, gnupg2, python:any (<< 2.8), python:any (>= 2.7.5-5~)
Description-en: utilities for signing GPG UIDs and prepare a signing party
 The PGP Individual UID Signer (PIUS) is a set of tools for individually
 signing all of the UIDs on a set of keys and encrypt-emailing each
 one to its respective email address. This drastically reduces t

Bug#845285: O: vblade -- virtual AoE blade emulator

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of vblade, David Martínez Moreno ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: vblade
Binary: vblade
Version: 20-1
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>= 6), quilt (>= 0.46-7)
Architecture: any
Standards-Version: 3.8.2
Format: 1.0
Files:
 490919a20bbc9310042faf170990dee5 969 vblade_20-1.dsc
 3c80e4a6bc7d66ae0c235b88cb44bd59 26689 vblade_20.orig.tar.gz
 25c42f77616d52d1c86102f2ea5467af 4323 vblade_20-1.diff.gz
Checksums-Sha1:
 b8fee61e97c326e02c3340c7d3442cec10ddf974 969 vblade_20-1.dsc
 610806305774832358603beac5fd6338f363db65 26689 vblade_20.orig.tar.gz
 e184beaa8a3120c3053ce3b9893870d57ba0b731 4323 vblade_20-1.diff.gz
Checksums-Sha256:
 8d3b277730d31b5a17d201230dfaa38d81429f82532e309f929680ab40774537 969 
vblade_20-1.dsc
 c8fe2fc4f2fba8e07e5cfdf17335982584eef2cd5c78bf8b1db93f2b56e7121d 26689 
vblade_20.orig.tar.gz
 e1cb11ea5188a9700a17a5530411319dce20b0821b95108f9460dd4b611db87a 4323 
vblade_20-1.diff.gz
Homepage: http://aoetools.sf.net
Directory: pool/main/v/vblade
Priority: source
Section: admin

Package: vblade
Binary: vblade
Version: 20-1
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>= 6), quilt (>= 0.46-7)
Architecture: any
Standards-Version: 3.8.2
Format: 1.0
Files:
 490919a20bbc9310042faf170990dee5 969 vblade_20-1.dsc
 3c80e4a6bc7d66ae0c235b88cb44bd59 26689 vblade_20.orig.tar.gz
 25c42f77616d52d1c86102f2ea5467af 4323 vblade_20-1.diff.gz
Checksums-Sha256:
 8d3b277730d31b5a17d201230dfaa38d81429f82532e309f929680ab40774537 969 
vblade_20-1.dsc
 c8fe2fc4f2fba8e07e5cfdf17335982584eef2cd5c78bf8b1db93f2b56e7121d 26689 
vblade_20.orig.tar.gz
 e1cb11ea5188a9700a17a5530411319dce20b0821b95108f9460dd4b611db87a 4323 
vblade_20-1.diff.gz
Homepage: http://aoetools.sf.net
Directory: pool/main/v/vblade
Priority: source
Section: admin

Package: vblade
Binary: vblade
Version: 22-1
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>= 9)
Architecture: any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 7719e2289a0de183d3dff80f1c866b12 1778 vblade_22-1.dsc
 510d98ba0f231284a5fbe2da11cb2d6e 26786 vblade_22.orig.tar.gz
 1a36d23e2eb4e23ebcfcf4ba6c84d776 5340 vblade_22-1.debian.tar.xz
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/vblade.git
Vcs-Git: git://anonscm.debian.org/collab-maint/vblade.git
Checksums-Sha256:
 81cba8515d0bb26e64e083e9e131d300327c3eb97fecdefdfa8fe6e9c6869896 1778 
vblade_22-1.dsc
 a990378f273f10eb431e42954a871aed52714035bbab28c54cef600c458356bb 26786 
vblade_22.orig.tar.gz
 32bf283c8905e5cd87286411b2d0c0b6ec09d549d1cb6d41c6c09c85cf4325de 5340 
vblade_22-1.debian.tar.xz
Homepage: http://aoetools.sf.net
Package-List: 
 vblade deb admin optional arch=any
Directory: pool/main/v/vblade
Priority: source
Section: admin

Package: vblade
Version: 22-1
Installed-Size: 43
Maintainer: David Martínez Moreno 
Architecture: amd64
Depends: libc6 (>= 2.7)
Recommends: vblade-persist
Description-en: virtual AoE blade emulator
 The vblade is the virtual EtherDrive (R) blade, a program that makes a
 seekable file available over an ethernet local area network (LAN) via
 the ATA over Ethernet (AoE) protocol.
 .
 The seekable file is typically a block device like /dev/md0 but even
 regular files will work.  Sparse files can be especially convenient.
 When vblade exports the block storage over AoE it becomes a storage
 target.  Another host on the same LAN can access the storage if it has
 a compatible aoe kernel driver.
Description-md5: fe793de0deb8ad57b766bf0f1b186c3f
Homepage: http://aoetools.sf.net
Tag: role::program, scope::utility
Section: admin
Priority: optional
Filename: pool/main/v/vblade/vblade_22-1_amd64.deb
Size: 17194
MD5sum: d8f399208310c433382e17b234a3b942
SHA256: 500d40427a26c8263e8b159f3a1c197401a395d6c15abe0c1bececdb31385388

Package: vblade
Version: 20-1
Installed-Size: 44
Maintainer: David Martínez Moreno 
Architecture: amd64
Depends: libc6 (>= 2.2.5)
Recommends: vblade-persist
Description-en: virtual AoE blade emulator
 The vblade is the virtual EtherDrive (R) blade, a program that makes a
 seekable file available over an ethernet local area network (LAN) via
 the ATA over Ethernet (AoE) protocol.
 .
 The seekable file is typically a block device like /dev/md0 but even
 regular files will work.  Sparse files can be especially convenient.
 When vblade exports the block storage over AoE it becomes a storage
 target.  Another host on the same LAN can access the storage if it has
 a compatible aoe kernel driver.
Description-md5: fe793de0deb8ad57b766bf0f1b186c3f
Homepage: http://aoetools.sf.net
Tag: role::program, 

Bug#845283: O: glob2 -- innovative Real Time Strategy game

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of glob2, David Martínez Moreno ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: glob2
Binary: glob2, glob2-data
Version: 0.9.4.4-2.3
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>> 6.0.0), quilt (>= 0.40), scons, libsdl1.2-dev (>= 
1.2.0), libsdl-image1.2-dev (>= 1.2.0), libsdl-net1.2-dev (>= 1.2.0), 
libsdl-ttf2.0-dev, libglu1-mesa-dev | libglu-dev, libvorbis-dev, libspeex-dev, 
libfreetype6-dev, libboost-dev, libboost-thread-dev, libboost-system-dev, 
libboost-date-time-dev, libfribidi-dev, portaudio19-dev, libboost-math-dev, 
bsdiff, sharutils
Architecture: any all
Standards-Version: 3.8.4
Format: 1.0
Files:
 f8eb01ec2356eb65da46d3b5453c0556 1448 glob2_0.9.4.4-2.3.dsc
 94c527325f355a29a2807f8f18a6e6a8 11338986 glob2_0.9.4.4.orig.tar.gz
 75c41c21cbcc740805907c71fa0a982e 24766 glob2_0.9.4.4-2.3.diff.gz
Checksums-Sha1:
 06d98bd105daf1e0484e7802a87b9b23c8719b3a 1448 glob2_0.9.4.4-2.3.dsc
 14aa8d840ef5f95a9af591789082fe2322fa8cad 11338986 glob2_0.9.4.4.orig.tar.gz
 fe083310358a5b1ad1c7f954ec2298cdffe4a283 24766 glob2_0.9.4.4-2.3.diff.gz
Checksums-Sha256:
 6b3ae0f3cd2acf1da9c96828c5a031963ef7a071b9c88e2150b48c9c44feb0a7 1448 
glob2_0.9.4.4-2.3.dsc
 0f4d898ec6b05ce27b4a12ef242cc26571304b90d2509932a4743c71311314b8 11338986 
glob2_0.9.4.4.orig.tar.gz
 482b55eac646ac61bc9161a08b38f765bb8a46d6b201d9c2613ccda07da52795 24766 
glob2_0.9.4.4-2.3.diff.gz
Homepage: http://globulation2.org
Package-List: 
 glob2 deb games optional arch=any
 glob2-data deb games optional arch=all
Directory: pool/main/g/glob2
Priority: source
Section: games

Package: glob2
Binary: glob2, glob2-data
Version: 0.9.4.4-2.5
Maintainer: David Martínez Moreno 
Build-Depends: debhelper (>> 6.0.0), quilt (>= 0.40), scons, libsdl1.2-dev (>= 
1.2.0), libsdl-image1.2-dev (>= 1.2.0), libsdl-net1.2-dev (>= 1.2.0), 
libsdl-ttf2.0-dev, libglu1-mesa-dev | libglu-dev, libvorbis-dev, libspeex-dev, 
libfreetype6-dev, libboost-dev, libboost-thread-dev, libboost-system-dev, 
libboost-date-time-dev, libfribidi-dev, portaudio19-dev, libboost-math-dev, 
bsdiff, sharutils
Architecture: any all
Standards-Version: 3.8.4
Format: 1.0
Files:
 0c8f404024fbe1741f3af4d1c0598d26 2224 glob2_0.9.4.4-2.5.dsc
 94c527325f355a29a2807f8f18a6e6a8 11338986 glob2_0.9.4.4.orig.tar.gz
 4a9c42ff0680e5f7833a1425649ce39d 27549 glob2_0.9.4.4-2.5.diff.gz
Checksums-Sha256:
 932f3f57102e6433760887a63721682014ef9932ec851ac2d6d468de29fd6cc5 2224 
glob2_0.9.4.4-2.5.dsc
 0f4d898ec6b05ce27b4a12ef242cc26571304b90d2509932a4743c71311314b8 11338986 
glob2_0.9.4.4.orig.tar.gz
 6d485089bb8f510a1295b60a4a777673e007b7dfdeaee7ee1ee28524a795c71c 27549 
glob2_0.9.4.4-2.5.diff.gz
Homepage: http://globulation2.org
Package-List: 
 glob2 deb games optional arch=any
 glob2-data deb games optional arch=all
Directory: pool/main/g/glob2
Priority: source
Section: games

Package: glob2
Source: glob2 (0.9.4.4-2.5)
Version: 0.9.4.4-2.5+b1
Installed-Size: 4545
Maintainer: David Martínez Moreno 
Architecture: amd64
Replaces: glob2-data (<< 0.9.2)
Depends: libboost-system1.62.0, libboost-thread1.62.0, libc6 (>= 2.14), 
libfribidi0 (>= 0.19.2), libgcc1 (>= 1:3.0), libgl1-mesa-glx | libgl1, 
libglu1-mesa | libglu1, libportaudio2 (>= 19+svn20101113), libsdl-image1.2 (>= 
1.2.10), libsdl-net1.2, libsdl-ttf2.0-0, libsdl1.2debian (>= 1.2.11), libspeex1 
(>= 1.2~beta3-1), libstdc++6 (>= 5.2), libvorbisfile3 (>= 1.1.2), zlib1g (>= 
1:1.1.4), glob2-data (= 0.9.4.4-2.5)
Description-en: innovative Real Time Strategy game
 Globulation 2 is an ongoing, multi-platform project to create innovative
 high-quality RTS gameplay, minimizing micro-management and assigning tasks
 to the units automatically. You just have to order the number of units you
 want for a selected task and the units will do their best to satisfy your
 requirements.
 .
 Glob2 can be played by a single player, through your Local Area Network,
 or over the Internet, thanks to the Ysagoon Online Gaming meta-server. It
 also features a scripting language for versatile gameplay and an integrated
 map editor.
Description-md5: b38ff913791741efa07b5bd47dbb1f7e
Homepage: http://globulation2.org
Tag: game::strategy, implemented-in::c, interface::graphical, interface::x11,
 network::client, role::program, uitoolkit::sdl, use::editing,
 use::gameplaying, x11::application
Section: games
Priority: optional
Filename: pool/main/g/glob2/glob2_0.9.4.4-2.5+b1_amd64.deb
Size: 956934
MD5sum: 1acfdc2607c1deb1dd297b9ae6b5d7f3
SHA256: 441d2d513ea3824338f82fee8192940c255ccc2a47a3c4618834b8e50013a159

Package: glob2
Version: 0.9.4.4-2.3
Installed-Size: 4400

Bug#845282: pcsc-tools: please make the build reproducible (buildpath)

[Daniel Shahaf]

Source: pcsc-tools
Version: 1.4.27-1
Severity: wishlist
Tags: upstream patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that pcsc-tools could not be built reproducibly.

Specifically, the build process embeds a (munged version of) the
absolute source directory in the package:


https://tests.reproducible-builds.org/debian/dbdtxt/unstable/amd64/pcsc-tools_1.4.27-1.diffoscope.txt
# Build directory: /build/pcsc-tools-1.4.27/2nd
   0x19d000 5620312e 342e3237.V 1.4.27
+  0x19e0 2f326e64 20286329 20323030 312d3230 /2nd (c) 2001-20
+  0x19f0 31312c20 4c75646f 76696320 526f7573 11, Ludovic Rous
+  0x1a00 73656175 203c6c75 646f7669 632e726f seau .

Patch attached.

[[[
--- a/Makefile
+++ b/Makefile
@@ -5,7 +5,7 @@
 # by default install in /usr/local
 DESTDIR ?= /usr/local
 
-VERSION := $(shell pwd | sed s/.*tools-//)
+VERSION := $(shell https://wiki.debian.org/ReproducibleBuilds

Bug#845240: ITP: node-string-width -- Get the visual width of a string

[Pirate Praveen]

On Mon, 21 Nov 2016 18:38:03 +0100 Paolo Greppi 
wrote:
> 3. to patch it to replace the dependency on is-fullwidth-code-point with
> node-wcwidth.js (https://packages.debian.org/sid/node-wcwidth.js) as per
> this suggestion: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842191#10

Try sending the patch upstream too (though the upstream is known to not
accept bugs with excuses like 'it works for 99% or the cases').



signature.asc
Description: OpenPGP digital signature

Bug#845281: mediawiki: backport version does not play well with extensions

[duck]

Package: mediawiki
Version: 1:1.27.1-2~bpo8+1
Severity: important


Quack,

If you try to upgrade to the bpo version and you already add 
mediawiki-extensions installed, the later is to be uninstalled. I 
understand that the new mediawiki package replaces (and in fact 
provides) the content of mediawiki-extensions-base now, same for 
mediawiki-extensions-confirmedit and mediawiki-extensions-geshi, but 
mediawiki-extensions dragged more packages which are then removed as 
well.


So, it seems to me you package should "Provides" these three packages, 
in order to play well with mediawiki-extensions. The exact upgrade path 
needs to be tested. Or you could package a new version of 
mediawiki-extensions without them and change the minimum requirement in 
mediawiki. I'll leave finding the best solution to your care.


Regards.
\_o<

--
Marc Dequènes

Bug#844789: [Debian-science-sagemath] gap: bad interaction between SAGE/atomic_write and GAP/SaveWorkspace [WAS: issue related to compressed manual.six]

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I am getting a better picture of what is going on.

On 20/11/16 00:54, Jerome BENOIT wrote:
> 
> 
> On 19/11/16 18:37, Jerome BENOIT wrote:
>> Hello,
> 
>> On 19/11/16 17:43, Bill Allombert wrote:
>>> On Sat, Nov 19, 2016 at 05:18:37AM +, Jerome BENOIT wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Hello Forum,

 as a matter of fact, discarding the patch 
 /debian/patches/fix-compressed-six-files
 fixes the doctests failures related to gap (and libgap).

 I have just uploaded un unpatched version of gap at the deb-sci-sage 
 repository:
 please double check !
> 
>>> Hello Jerome,
>>> If I remove fix-compressed-six-files and rebuild the packages, then GAP
>>> is unable to read compressed old-style .six files.
> 
>>> For example install gap-alnuth and do
>>> ?FieldByMatrices
> 
>> Indeed, I can reproduce this issue on two distinct schroots, one with the 
>> patch applied and one without it.
> 
> 
> 
>>> With the patch fix-compressed-six-files applied, I get
>>> gap> ?FieldByMatrices
>>> Help: several entries match this topic - type ?2 to get match [2]
> 
>>> [1] Alnuth: FieldByMatrices
>>> [2] Alnuth: FieldByMatricesNC
> 
>>> With the patch removed fix-compressed-six-files, I get
> 
>>> gap> ?FieldByMatrices
>>> Help: no matching entry found
>>> Help: 'FieldByMatrices' is currently undocumented.
>>>   For details, try ?Undocumented Variables
> 
>>> which is wrong.
> 
> What I meant is that I can reproduce this results.
> 
> 
>>> New-style .six files start by a comment lines so are not affected by the
>>> upstream gap bug (which cause the first line to be lost, because rewind
>>> does not work on pipe).
> 
> First the issue on Sage also occurs for the new format (#SIXFORMAT ).
> In fact, it occurs only when the manual.six is compressed: if, for debugging 
> purpose,
> each installed compressed manual.six is uncompressed, the doctests involving 
> compressed manual.six
> become successful.
> 
> So the issue seems also related to the patch fix-gzip-stringfile which was 
> integrated in the last version of GAP.
> In the header of the patch, we read: `We use pipes for reading gzipped files'.
> What leads me to the question: why we do not use zlib instead ?
> 
> I have also noticed that Sage[Math] works in GAP `-p' mode, what is a bit 
> confusing for me now. 
> 
> 
>>> So it seems to me you need to apply fix-compressed-six-files to libgap
>>> also.
> 
>> The path fix-compressed-six-files does not affect libgap since it patchs 
>> only a GAP Include file,
>> more precisely /lib/helpbase.gi , while libgap deals with none of them.
>> libgap only deals with the file in /src  [1,2]
>> Second, the patches that deal with the material in /src are applied [3].
> 
>> [1] 
>> http://sources.debian.net/src/libgap-sage/4.8.6%2B3%2B20160327g69a66f0%2Bdsx-1/debian/get-orig-source.sh/
>> [2] 
>> http://sources.debian.net/src/libgap-sage/4.8.6%2B3%2B20160327g69a66f0%2Bdsx-1/debian/rules/
>> [3] 
>> http://sources.debian.net/src/libgap-sage/4.8.6%2B3%2B20160327g69a66f0%2Bdsx-1/debian/patches/series/
>>  (the two first ones)
> 
>> So now, I think that the patch fix-compressed-six-files might be improved.
> 
>> But before, we must find a way to reproduce in `pure' GAP the issue 
>> effectively observed within Sage.

So far I found no way to reproduce is in pure GAP. In fact the patch 
/debian/patches/fix-compressed-six-files is
only evil because it raises an issue which is otherwise eaten/hidden .

Having a look to /tmp/gapsage.log shows that something wrong happens with the 
GAP function SaveWorkspace within
the atomic_write with-environment. The involved part is implemented in 
/sage/src/sage/interfaces/gap.py ,
in the method save_workspace of the class Gap .

To get /tmp/gapsage.log , you have to uncomment out the second bottom line of 
debian/build/usr/share/sage/ext/gap/sage.g .
Grossely this trace file contains the GAP IO.

Currently if you run from  the test-command 

$ ( cd sage; ./sage -t -d --long src/sage/interfaces/gap.py )

you get a Failed example. The interesting part is not here but in 
/tmp/gapsage.log :
up to the sage1 line, all is fine. Then we have an array of random bytes 
followed by the example failure.
With appropriate GAP Print, we can see that the random bytes are printed by 
SaveWorkspace within the
atomic_write with-environment implemented in 
/sage/src/sage/interfaces/gap.py .
Placing the SaveWorkspace outside this atomic_write with-environment (e.g., 
SaveWorkspace("/tmp/workspace-XX");)
give a True as GAP output (and we obtained other kind of failures).

I guess that the random bytes in /tmp/gapsage.log are not expected at all, and 
that they somehow feed some GAP variable.
My current assumption is that the unpatched GAP (i.e., the upstream version) is 
blind to those random bytes, while the patched
version (the one effectively in Debian unstable) is not, and it is gettin

Bug#845280: apt: useless path given in failed install messages

[Adam Borowski]

Package: apt
Version: 1.3.1
Severity: normal


Hi!
When installation of a package fails, recent apt makes dpkg print useless
paths in the error message:

dpkg: error processing archive 
/tmp/apt-dpkg-install-iwKqmD/4-libxtables12_1.6.0+snapshot20161117-2_amd64.deb 
(--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libxtables.so.12.0.0', which is 
also in package libxtables11:amd64 1.6.0+snapshot20161117-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /tmp/apt-dpkg-install-iwKqmD/4-libxtables12_1.6.0+snapshot20161117-2_amd64.deb

Until recently, the path given was to /var/cache/apt/archives/ where
.deb files are actually kept.  I see they are now copied to
/tmp/apt-dpkg-install-iwKqmD/ and prefixed by ordinal numbers, but that
temporary directory ceases to exist before apt returns, thus is useless to
the user.



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

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

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2014.3
ii  gpgv2.1.16-2
ii  init-system-helpers 1.46
ii  libapt-pkg5.0   1.3.1
ii  libc6   2.24-5
ii  libgcc1 1:6.2.1-4
ii  libstdc++6  6.2.1-4

Versions of packages apt recommends:
ii  gnupg  2.1.16-2

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.18.15
ii  powermgmt-base   1.31+nmu1
ii  python-apt   1.1.0~beta5

-- no debconf information

Bug#845279: freeimage FTCBFS: uses build architecture compiler and pkg-config

[Helmut Grohne]

Source: freeimage
Version: 3.17.0+ds1-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

freeimage fails to cross build from source, because it generally uses
the build architecture toolchain. Supplying a triplet-prefixed CC and
CXX solves most of it, but the upstream Makefile calls directly into an
unprefixed pkg-config. The attached patch addresses both issues and
makes freeimage cross build successfully. Please consider applying it.

Helmut
--- freeimage-3.17.0+ds1/debian/changelog
+++ freeimage-3.17.0+ds1/debian/changelog
@@ -1,3 +1,10 @@
+freeimage (3.17.0+ds1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use triplet-prefixed build tools (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 22 Nov 2016 06:12:06 +0100
+
 freeimage (3.17.0+ds1-3) unstable; urgency=critical
 
   [ Ghislain Antony Vaillant ]
--- freeimage-3.17.0+ds1/debian/patches/cross.patch
+++ freeimage-3.17.0+ds1/debian/patches/cross.patch
@@ -0,0 +1,31 @@
+From: Helmut Grohne 
+Subject: make pkg-config substitutable with triplet-prefixed tools
+
+--- freeimage-3.17.0+ds1.orig/Makefile.gnu
 freeimage-3.17.0+ds1/Makefile.gnu
+@@ -10,8 +10,9 @@
+ 
+ # Converts cr/lf to just lf
+ DOS2UNIX = dos2unix
++PKG_CONFIG ?= pkg-config
+ 
+-LIBRARIES = -lstdc++ -ljxrglue $(shell pkg-config --libs libjpeg libopenjp2 
libpng libraw libtiff-4 libwebpmux OpenEXR zlib) -lm
++LIBRARIES = -lstdc++ -ljxrglue $(shell $(PKG_CONFIG) --libs libjpeg 
libopenjp2 libpng libraw libtiff-4 libwebpmux OpenEXR zlib) -lm
+ 
+ MODULES = $(SRCS:.c=.o)
+ MODULES := $(MODULES:.cpp=.o)
+@@ -23,12 +24,12 @@
+ override CFLAGS += -DNO_LCMS
+ # LibJXR
+ override CFLAGS += -DDISABLE_PERF_MEASUREMENT -D__ANSI__
+-override CFLAGS += $(INCLUDE) -I/usr/include/jxrlib $(shell pkg-config 
--cflags libjpeg libopenjp2 libpng libraw libtiff-4 libwebpmux OpenEXR zlib)
++override CFLAGS += $(INCLUDE) -I/usr/include/jxrlib $(shell $(PKG_CONFIG) 
--cflags libjpeg libopenjp2 libpng libraw libtiff-4 libwebpmux OpenEXR zlib)
+ CXXFLAGS ?= -O3 -fPIC
+ override CXXFLAGS += -fexceptions -fvisibility=hidden -Wno-ctor-dtor-privacy
+ # LibJXR
+ override CXXFLAGS += -D__ANSI__
+-override CXXFLAGS += $(INCLUDE) -I/usr/include/jxrlib $(shell pkg-config 
--cflags libjpeg libopenjp2 libpng libraw libtiff-4 libwebpmux OpenEXR zlib)
++override CXXFLAGS += $(INCLUDE) -I/usr/include/jxrlib $(shell $(PKG_CONFIG) 
--cflags libjpeg libopenjp2 libpng libraw libtiff-4 libwebpmux OpenEXR zlib)
+ 
+ TARGET  = freeimage
+ STATICLIB = lib$(TARGET).a
--- freeimage-3.17.0+ds1/debian/patches/series
+++ freeimage-3.17.0+ds1/debian/patches/series
@@ -12,3 +12,4 @@
 Fix-CVE-2015-0852.patch
 Fix-encoding-of-fi-header.patch
 Fix-CVE-2016-5684.patch
+cross.patch
--- freeimage-3.17.0+ds1/debian/rules
+++ freeimage-3.17.0+ds1/debian/rules
@@ -7,7 +7,14 @@
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 # Environment information.
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC := $(DEB_HOST_GNU_TYPE)-gcc
+endif
+ifeq ($(origin CXX),default)
+CXX := $(DEB_HOST_GNU_TYPE)-g++
+endif
+export PKG_CONFIG ?= $(DEB_HOST_GNU_TYPE)-pkg-config
 
 # Installation paths.
 DESTDIR = $(CURDIR)/debian/tmp
@@ -27,8 +34,8 @@
dh_autoreconf $(MAKE) -- -f $(CURDIR)/debian/rules gen-src-list
 
 override_dh_auto_build-arch:
-   $(MAKE) CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(LDFLAGS)"
-   $(MAKE) -f Makefile.fip CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" 
LDFLAGS="$(LDFLAGS)"
+   $(MAKE) CC="$(CC)" CXX="$(CXX)" CFLAGS="$(CFLAGS)" 
CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(LDFLAGS)"
+   $(MAKE) -f Makefile.fip CC="$(CC)" CXX="$(CXX)" CFLAGS="$(CFLAGS)" 
CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(LDFLAGS)"
 
 override_dh_auto_build-indep:
cd $(CURDIR)/Wrapper/FreeImagePlus/doc && doxygen FreeImagePlus.dox

Bug#845272: ITP: libopenhmd -- API and drivers for immersive technology (shared library)

[Paul Wise]

On Tue, Nov 22, 2016 at 7:45 AM, Balint Reczey wrote:

> OpenHMD aims to provide a Free and Open Source API and drivers for
> immersive technology, such as head mounted displays with built in head
> tracking.

You may want to add some metadata about which hardware is supported:

https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#845278: libxtables12: can't be installed

[Gabriel Filion]

Gabriel Filion:
> I've just exerienced the same during an upgrade of sid packages.
> 
> The only way to break out of this mess is to force the upgrade of the
> package with:
> 
> dpkg --force-overwrite -i
> /var/cache/apt/archives/libxtables12_1.6.0+snapshot20161117-2_amd64.deb
> 
> then it becomes possible to continue with the rest of the upgrade.
> 
> libxtables12 seems like it should have a "breaks: libxtables11", or
> replaces: (I'm not sure if the latter is actually appropriate in this
> situation)

Seems like this is not the only thing missing.

nftables is still depending on libxtables11. if I try to apt remove
libxtables11 after running the dpkg command above, I get:

The following packages will be REMOVED:
  libxtables11 nftables

so the upgrade to libxtables12 would be breaking nftables with the
correct dependency to break libxtables11



signature.asc
Description: OpenPGP digital signature

Bug#845278:

[Paul R. Tagliamonte]

Yeah, same here on a sid system:

Preparing to unpack .../libxtables12_1.6.0+snapshot20161117-2_amd64.deb ...
Unpacking libxtables12:amd64 (1.6.0+snapshot20161117-2) ...
dpkg: error processing archive
/var/cache/apt/archives/libxtables12_1.6.0+snapshot20161117-2_amd64.deb
(--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libxtables.so.12.0.0',
which is also in package libxtables11:amd64 1.6.0+snapshot20161117-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libxtables12_1.6.0+snapshot20161117-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

However, the old package wasn't used anymore, so a dpkg --purge
libxtables11:amd64, and an apt-get install -f did the trick.

Seems like a Conflicts/Breaks might be best here, apt can just get rid
of the other package.

  Paul

Bug#844608: Looking for sponsor for protobuf NMU

[lumin]

Hi,

I prepared an NMU for protobuf for adding
python3-protobuf binary package, and now
I'm asking for maintainer comments and
looking for sponsor.

The package is available at 
https://mentors.debian.net/package/protobuf
https://mentors.debian.net/debian/pool/main/p/protobuf/protobuf_3.0.0-7.1.dsc

And it passed debomatic-amd64 test:
http://debomatic-amd64.debian.net/distribution#unstable/protobuf/3.0.0-7.1/buildlog

Thanks!

P.S. The latest patch is attached.diff -Nru protobuf-3.0.0/debian/changelog protobuf-3.0.0/debian/changelog
--- protobuf-3.0.0/debian/changelog	2016-09-02 06:57:13.0 +
+++ protobuf-3.0.0/debian/changelog	2016-11-17 13:30:28.0 +
@@ -1,3 +1,12 @@
+protobuf (3.0.0-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build python3-protobuf, thanks to Thomas Viehmann. (Closes: #836821)
+  * Add the missing B-D "libgtest-dev". (Closes: #836826)
+  * Add "python3-six" to B-D, which is required by python3 test.
+
+ -- Zhou Mo   Thu, 17 Nov 2016 13:30:28 +
+
 protobuf (3.0.0-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru protobuf-3.0.0/debian/clean protobuf-3.0.0/debian/clean
--- protobuf-3.0.0/debian/clean	2016-08-21 08:54:48.0 +
+++ protobuf-3.0.0/debian/clean	2016-11-17 13:30:28.0 +
@@ -1 +1,3 @@
 protoc.1
+debian/autoreconf.after
+debian/autoreconf.before
diff -Nru protobuf-3.0.0/debian/control protobuf-3.0.0/debian/control
--- protobuf-3.0.0/debian/control	2016-08-25 22:28:51.0 +
+++ protobuf-3.0.0/debian/control	2016-11-17 13:30:28.0 +
@@ -16,12 +16,17 @@
  , g++ (>= 4:4.7)
  , zlib1g-dev
  , google-mock
+ , libgtest-dev
 # Python
  , dh-python
  , python-all (>= 2.7)
  , libpython-all-dev (>= 2.7)
+ , python3-all (>= 3.3)
+ , libpython3-all-dev (>= 3.3)
  , python-setuptools
+ , python3-setuptools
  , python-google-apputils
+ , python3-six
 # Manpage generator
  , xmlto
 # Tests
@@ -180,6 +185,27 @@
  need the protoc tool (in the protobuf-compiler package) to compile your
  definition to Python classes, and then the modules in this package will allow
  you to use those classes in your programs.
+
+Package: python3-protobuf
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Description: Python 3 bindings for protocol buffers
+ Protocol buffers are a flexible, efficient, automated mechanism for
+ serializing structured data - similar to XML, but smaller, faster, and
+ simpler. You define how you want your data to be structured once, then you can
+ use special generated source code to easily write and read your structured
+ data to and from a variety of data streams and using a variety of languages.
+ You can even update your data structure without breaking deployed programs
+ that are compiled against the "old" format.
+ .
+ Google uses Protocol Buffers for almost all of its internal RPC protocols and
+ file formats.
+ .
+ This package contains the Python 3 bindings for the protocol buffers. You will
+ need the protoc tool (in the protobuf-compiler package) to compile your
+ definition to Python classes, and then the modules in this package will allow
+ you to use those classes in your programs.
 
 Package: libprotobuf-java
 Architecture: all
diff -Nru protobuf-3.0.0/debian/python-protobuf3.README.Debian protobuf-3.0.0/debian/python-protobuf3.README.Debian
--- protobuf-3.0.0/debian/python-protobuf3.README.Debian	1970-01-01 00:00:00.0 +
+++ protobuf-3.0.0/debian/python-protobuf3.README.Debian	2016-11-17 13:30:28.0 +
@@ -0,0 +1,11 @@
+C++ backend
+===
+
+As of protobuf 2.6.0, a new C++ backend for the Python protobuf bindings is
+available, which is faster than the default pure Python implementation. It can
+be activated by setting the following environment variables:
+
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION_VERSION=2
+
+ -- Robert Edmonds   Thu, 28 Aug 2014 21:10:30 -0700
diff -Nru protobuf-3.0.0/debian/rules protobuf-3.0.0/debian/rules
--- protobuf-3.0.0/debian/rules	2016-08-25 00:28:25.0 +
+++ protobuf-3.0.0/debian/rules	2016-11-17 13:30:28.0 +
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with autoreconf,python2 --parallel
+	dh $@ --with autoreconf,python2,python3 --parallel
 
 override_dh_auto_build-arch:
 ## Chicken<->Egg problem: protobuf requires self-generated .pb.go files to
@@ -14,8 +14,10 @@
 	# Generate the manpage.
 	xmlto man debian/protoc.xml
 
-	# Python build.
+	# Python and Python3 build.
+	cp -rv python python3
 	cd python && python setup.py build --cpp_implementation
+	cd python3 && python3 setup.py build --cpp_implementation
 
 override_dh_auto_build-indep:
 	dh_auto_build --indep
@@ -42,8 +44,14 @@
 	# Python test.
 	set -e; \
 	export LD_LIBRARY_PATH=$(CURDIR)/src/.libs; \
-	cd python && for python in $(shell pyversions -r); do \
-		$$python setup.py test --cpp_implementation; \
+	cd python && for PYTHON in $(shel

Bug#844608: Acknowledgement (RFS: protobuf/3.0.0-7.1 [NMU])

[lumin]

Hi,

I just updated the package on mentors,
https://mentors.debian.net/debian/pool/main/p/protobuf/protobuf_3.0.0-7.1.dsc
https://mentors.debian.net/package/protobuf

And it passed the build on debomatic-amd64
http://debomatic-amd64.debian.net/distribution#unstable/protobuf/3.0.0-7.1/buildlog

The updated patch is attached.diff -Nru protobuf-3.0.0/debian/changelog protobuf-3.0.0/debian/changelog
--- protobuf-3.0.0/debian/changelog	2016-09-02 06:57:13.0 +
+++ protobuf-3.0.0/debian/changelog	2016-11-17 13:30:28.0 +
@@ -1,3 +1,12 @@
+protobuf (3.0.0-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build python3-protobuf, thanks to Thomas Viehmann. (Closes: #836821)
+  * Add the missing B-D "libgtest-dev". (Closes: #836826)
+  * Add "python3-six" to B-D, which is required by python3 test.
+
+ -- Zhou Mo   Thu, 17 Nov 2016 13:30:28 +
+
 protobuf (3.0.0-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru protobuf-3.0.0/debian/clean protobuf-3.0.0/debian/clean
--- protobuf-3.0.0/debian/clean	2016-08-21 08:54:48.0 +
+++ protobuf-3.0.0/debian/clean	2016-11-17 13:30:28.0 +
@@ -1 +1,3 @@
 protoc.1
+debian/autoreconf.after
+debian/autoreconf.before
diff -Nru protobuf-3.0.0/debian/control protobuf-3.0.0/debian/control
--- protobuf-3.0.0/debian/control	2016-08-25 22:28:51.0 +
+++ protobuf-3.0.0/debian/control	2016-11-17 13:30:28.0 +
@@ -16,12 +16,17 @@
  , g++ (>= 4:4.7)
  , zlib1g-dev
  , google-mock
+ , libgtest-dev
 # Python
  , dh-python
  , python-all (>= 2.7)
  , libpython-all-dev (>= 2.7)
+ , python3-all (>= 3.3)
+ , libpython3-all-dev (>= 3.3)
  , python-setuptools
+ , python3-setuptools
  , python-google-apputils
+ , python3-six
 # Manpage generator
  , xmlto
 # Tests
@@ -180,6 +185,27 @@
  need the protoc tool (in the protobuf-compiler package) to compile your
  definition to Python classes, and then the modules in this package will allow
  you to use those classes in your programs.
+
+Package: python3-protobuf
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Description: Python 3 bindings for protocol buffers
+ Protocol buffers are a flexible, efficient, automated mechanism for
+ serializing structured data - similar to XML, but smaller, faster, and
+ simpler. You define how you want your data to be structured once, then you can
+ use special generated source code to easily write and read your structured
+ data to and from a variety of data streams and using a variety of languages.
+ You can even update your data structure without breaking deployed programs
+ that are compiled against the "old" format.
+ .
+ Google uses Protocol Buffers for almost all of its internal RPC protocols and
+ file formats.
+ .
+ This package contains the Python 3 bindings for the protocol buffers. You will
+ need the protoc tool (in the protobuf-compiler package) to compile your
+ definition to Python classes, and then the modules in this package will allow
+ you to use those classes in your programs.
 
 Package: libprotobuf-java
 Architecture: all
diff -Nru protobuf-3.0.0/debian/python-protobuf3.README.Debian protobuf-3.0.0/debian/python-protobuf3.README.Debian
--- protobuf-3.0.0/debian/python-protobuf3.README.Debian	1970-01-01 00:00:00.0 +
+++ protobuf-3.0.0/debian/python-protobuf3.README.Debian	2016-11-17 13:30:28.0 +
@@ -0,0 +1,11 @@
+C++ backend
+===
+
+As of protobuf 2.6.0, a new C++ backend for the Python protobuf bindings is
+available, which is faster than the default pure Python implementation. It can
+be activated by setting the following environment variables:
+
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION_VERSION=2
+
+ -- Robert Edmonds   Thu, 28 Aug 2014 21:10:30 -0700
diff -Nru protobuf-3.0.0/debian/rules protobuf-3.0.0/debian/rules
--- protobuf-3.0.0/debian/rules	2016-08-25 00:28:25.0 +
+++ protobuf-3.0.0/debian/rules	2016-11-17 13:30:28.0 +
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with autoreconf,python2 --parallel
+	dh $@ --with autoreconf,python2,python3 --parallel
 
 override_dh_auto_build-arch:
 ## Chicken<->Egg problem: protobuf requires self-generated .pb.go files to
@@ -14,8 +14,10 @@
 	# Generate the manpage.
 	xmlto man debian/protoc.xml
 
-	# Python build.
+	# Python and Python3 build.
+	cp -rv python python3
 	cd python && python setup.py build --cpp_implementation
+	cd python3 && python3 setup.py build --cpp_implementation
 
 override_dh_auto_build-indep:
 	dh_auto_build --indep
@@ -42,8 +44,14 @@
 	# Python test.
 	set -e; \
 	export LD_LIBRARY_PATH=$(CURDIR)/src/.libs; \
-	cd python && for python in $(shell pyversions -r); do \
-		$$python setup.py test --cpp_implementation; \
+	cd python && for PYTHON in $(shell pyversions -r); do \
+		$$PYTHON setup.py test --cpp_implementation; \
+	done
+# Python3 test.
+	set -e; \
+	export LD_LIBRARY_PATH=$(

Bug#845278: libxtables12: can't be installed

[Gabriel Filion]

Hello,

I've just exerienced the same during an upgrade of sid packages.

The only way to break out of this mess is to force the upgrade of the
package with:

dpkg --force-overwrite -i
/var/cache/apt/archives/libxtables12_1.6.0+snapshot20161117-2_amd64.deb

then it becomes possible to continue with the rest of the upgrade.

libxtables12 seems like it should have a "breaks: libxtables11", or
replaces: (I'm not sure if the latter is actually appropriate in this
situation)



signature.asc
Description: OpenPGP digital signature

Bug#782054: Please support Dovecot Maildir++

[Guillem Jover]

Control: tag -1 fixed-upstream

On Sat, 2016-11-05 at 18:26:36 +0100, Oswald Buddenhagen wrote:
> i just pushed a fix to master.

This would be commit 0f24ca31b5fafe5228d0e99f460f1c823121b296, which
I've built into local packages from git master, and it finally fixes
my issue.

It would be nice if either a git snapshot could be packaged or this
patch cherry-picked.

Thanks,
Guillem

Bug#845278: libxtables12: can't be installed

[Christoph Anton Mitterer]

Package: libxtables12
Version: 1.6.0+snapshot20161117-2
Severity: grave
Justification: renders package unusable


Hi.

Unpacking libxtables12:amd64 (1.6.0+snapshot20161117-2) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-DBLJsg/0-libxtables12_1.6.0+snapshot20161117-2_amd64.deb 
(--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libxtables.so.12.0.0', which is 
also in package libxtables11:amd64 1.6.0+snapshot20161117-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)


Cheers,
Chris.


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

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

Bug#845277: undocumented need for large tmp directory when archiving large mailboxes

[Celejar]

Package: archivemail
Version: 0.9.0-1.1
Severity: normal

archivemail fails on large mailboxes:

Traceback (most recent call last):
  File "/usr/bin/archivemail", line 1951, in 
main()
  File "/usr/bin/archivemail", line 700, in main
archive(mailbox_path)
  File "/usr/bin/archivemail", line 1133, in archive
_archive_dir(mailbox_name, "mh")
  File "/usr/bin/archivemail", line 1266, in _archive_dir
archive.write(msg)
  File "/usr/bin/archivemail", line 566, in write
self.mbox_file.write(body)
  File "/usr/lib/python2.7/gzip.py", line 243, in write
self.fileobj.write( self.compress.compress(data) )
IOError: [Errno 28] No space left on device

This is despite the output directory ("-o some_directory") having plenty of
space. The problem is that archivemail constructs a temporary mailbox
containing all the messages to archive in the default temporary directory, and
will therefore fail if that directory is not large enough. I do not believe
this is documented in the program's documentation, and the program itself should
exit more gracefully and provide the user with a clearer explanation of the
problem. In any event, the solution is to use environment
variables to point archivemail toward a tmp directory with enough space, by
prefacing the call to archivemail with something like:

export TMPDIR=/some_dir


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

Kernel: Linux 4.4.30-lizzie (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 archivemail depends on:
ii  python  2.7.9-1

archivemail recommends no packages.

archivemail suggests no packages.

-- no debconf information

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

[Vincent Lefevre]

On 2016-11-22 00:37:14 +, Luca Boccassi wrote:
> In the end, you shouldn't have let aptitude remove the packages. It can
> happen from time to time on unstable to have temporary inconsistent
> state in the apt tree (that's why it's called unstable), for example in
> this case it was probably because the new amd64 version was up in the
> repo but the i386 was still being built/published.

The problem here is that aptitude said that the packages were
no longer used, i.e. there were no dependencies on them. This
is very misleading.

Still, there are missing Breaks.

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

Bug#845276: nmu: slepc_3.7.3+dfsg1-2+b1

[Drew Parsons]

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

slepc on hppa seems to have slipped through the cracks during the
hypre 2.11.1 transition

nmu slepc_3.7.3+dfsg1-2+b1 . hppa . unstable . -m "Rebuild against 
libhypre-2.11.1."

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

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

Bug#813639: (no subject)

[Marcos Mobley]

we're now over 2 years behind on this. could we please get an update so
that stretch releases with something not so old?

thanks




signature.asc
Description: OpenPGP digital signature

Bug#844579: console-setup: CyrAsia font missing Kazakh letter

[Baurzhan Muftakhidinov]

On Mon, Nov 21, 2016 at 9:54 PM, Anton Zinoviev  wrote:
> On Mon, Nov 21, 2016 at 08:20:52PM +0500, Baurzhan Muftakhidinov wrote:
>>
>> Should I prepare a patch for it? It is only 3 lines change.
>
> I suppose you shouldn't.
>
>> >> WARNING: U+2116: no glyph defined
>
> Hmm, now I realise that this looks very suspicious because the numero
> sign is defined in most (all?) source fonts.  I don't get such a message
> when I build the package.  What does the following command output:
>
> grep '2116: no glyph defined' Fonts/*.log
>
> Anton Zinoviev

Hi,

It shows couple dozen matches. I am building in chroot, could it be
that I missed something to install? I have installed deps with
apt-get build-dep console-setup

Fonts/CyrAsia-Fixed13.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed13.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed14.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed14.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed14.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed14.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed15.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed15.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed16.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed16.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed16.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed16.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed18.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Fixed18.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Terminus14.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Terminus14.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Terminus16.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-Terminus16.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-TerminusBold14.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-TerminusBold14.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-TerminusBold16.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-TerminusBold16.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-TerminusBoldVGA14.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-TerminusBoldVGA14.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-TerminusBoldVGA16.raw.log:WARNING: U+2116: no glyph defined
Fonts/CyrAsia-TerminusBoldVGA16.raw.log:WARNING: U+2116: no glyph defined

Bug#845275: apt tries to install alternate architectures of packages with -1 priority

[Raphaël Halimi]

Package: apt
Version: 1.3.1

Hi,

I had this snippet in /etc/apt/preferences.d/no-systemd-sysv :

-%<-
Explanation: keep SysV init
Package: systemd-sysv
Pin: release o=*
Pin-Priority: -1
->%-

During my tests to find the root cause of #844785, I tried to remove
dbus-user-session.

When I wanted to install it back, I had the surprise of seeing this:

-%<-
raph@arche:~$ sudo apt-get install dbus-user-session
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  cgmanager libcgmanager0 libnih-dbus1 libnih1
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  python-systemd systemd-sysv:i386
The following packages will be REMOVED:
  systemd-shim sysvinit-core
The following NEW packages will be installed:
  dbus-user-session python-systemd systemd-sysv:i386
0 upgraded, 3 newly installed, 2 to remove and 0 not upgraded.
Need to get 182 kB of archives.
After this operation, 74.8 kB of additional disk space will be used.
Do you want to continue? [Y/n]
->%-

Modifying the preferences file to specify both architectures fixed this:

-%<-
Explanation: keep SysV init
Package: systemd-sysv:i386 systemd-sysv:amd64
Pin: release o=*
Pin-Priority: -1
->%-

-%<-
raph@arche:~$ sudo apt-get install dbus-user-session
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
  systemd-sysv
The following NEW packages will be installed:
  dbus-user-session
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 74.9 kB of archives.
After this operation, 111 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package dbus-user-session.
(Reading database ... 248649 files and directories currently installed.)
Preparing to unpack .../dbus-user-session_1.10.12-1_all.deb ...
Unpacking dbus-user-session (1.10.12-1) ...
Setting up dbus-user-session (1.10.12-1) ...
->%-

Is it expected behavior, or a bug ?

Also, it may or may not be related (I can open a separate bug if you
want), but it's interesting to note that this snippet didn't work:

-%<-
Explanation: keep SysV init
Package: /systemd-sysv:(i386|amd64)/
Pin: release o=*
Pin-Priority: -1
->%-

Is it not a valid extended regexp ?

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#845274: googletest: FTBFS on hppa - needs to be built with -mlong-calls

[John David Anglin]

Package: googletest
Version: 1.8.0-2
Severity: normal

Dear Maintainer,

On hppa, the build fails here:

/usr/bin/c++   -g -O0 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time   
CMakeFiles/gmock-generated-matchers_test.dir/test/gmock-generated-matchers_test.cc.o
  -o gmock-generated-matchers_test -rdynamic libgmock_main.a -lpthread 
/usr/bin/ld: 
CMakeFiles/gmock-generated-matchers_test.dir/test/gmock-generated-matchers_test.cc.o(.text._ZN7testing8internal10NotMatcherINS0_23ElementsAreArrayMatcherIPKcEEEC2ERKS6_[_ZN7testing8internal10NotMatcherINS0_23ElementsAreArrayMatcherIPKcEEEC5ERKS6_]+0x48):
 cannot reach 
2b93__ZN7testing8internal23ElementsAreArrayMatcherIPKcEC1ERKS4_+0, 
recompile with -ffunction-sections
/usr/bin/ld: 
CMakeFiles/gmock-generated-matchers_test.dir/test/gmock-generated-matchers_test.cc.o(.text._ZN7testing8internal10NotMatcherINS0_23ElementsAreArrayMatcherIPKcEEEC2ERKS6_[_ZN7testing8internal10NotMatcherINS0_23ElementsAreArrayMatcherIPKcEEEC5ERKS6_]+0x48):
 cannot handle R_PARISC_PCREL17F for 
_ZN7testing8internal23ElementsAreArrayMatcherIPKcEC1ERKS4_
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
googlemock/CMakeFiles/gmock-generated-matchers_test.dir/build.make:98: recipe 
for target 'googlemock/gmock-generated-matchers_test' failed

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=googletest&arch=hppa&ver=1.8.0-2&stamp=1479624981

The above error is caused by a call stub table overflow or the inability
of a call to reach a long call stub.  The use of the -rdynamic option makes
this problem worse.

The problem can be avoided by compiling with the "-mlong-calls" options.
See the following URL for a successful build with this option:
https://buildd.debian.org/status/fetch.php?pkg=googletest&arch=hppa&ver=1.8.0-2&stamp=1479700635

Regards,
Dave Anglin

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.8.8+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages googletest depends on:
pn  python:any  

googletest recommends no packages.

googletest suggests no packages.

-- no debconf information

Bug#844530: [1/2] kbuild: provide include/asm/asm-prototypes.h for ARM

[Nicholas Piggin]

On Mon, 21 Nov 2016 19:13:55 +
Russell King - ARM Linux  wrote:

> On Mon, Nov 21, 2016 at 07:46:44PM +0100, Uwe Kleine-König wrote:
> > Hello,
> > 
> > On Mon, Oct 24, 2016 at 05:05:26PM +0200, Arnd Bergmann wrote:  
> > > This adds an asm/asm-prototypes.h header for ARM to fix the
> > > broken symbol versioning for symbols exported from assembler
> > > files.
> > > 
> > > In addition to the header, we have to do these other small
> > > changes:
> > > 
> > > - move the exports from bitops.h to {change,clear,set,...}bit.S
> > > - move the exports from csumpartialgeneric.S into the files
> > >   including it
> > > 
> > > I couldn't find the correct prototypes for the compiler builtins,
> > > so I went with the fake 'void f(void)' prototypes that we had
> > > before.
> > > 
> > > This leaves the mmioset/mmiocpy function for now, as it's not
> > > obvious how to best handle them.
> > > 
> > > Signed-off-by: Arnd Bergmann   
> > 
> > In my test builds of 4.9-rc5 plus
> > 
> > 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() for asm")
> > cc6acc11cad1 ("kbuild: be more careful about matching preprocessed asm 
> > ___EXPORT_SYMBOL")
> > 
> > (which are in -rc6) I got many warnings à la:
> > 
> > WARNING: "memset" [drivers/media/usb/airspy/airspy.ko] has no CRC!
> > 
> > and booting the resulting kernel failed with messages of the type:
> > 
> > [3.024126] usbcore: no symbol version for __memzero
> > [3.029107] usbcore: Unknown symbol __memzero (err -22)
> > 
> > so hardly any module could be loaded. modprobe -f works however, but
> > that's not what my initramfs does.
> > 
> > With this patch and https://patchwork.kernel.org/patch/9392291/ ("ARM:
> > move mmiocpy/mmioset exports to io.c") I could compile a kernel without
> > CRC warnings and it boots fine. So it would be great to get these two
> > patches into 4.9.  
> 
> Yea, many things would be nice, but I've been unable to track the
> issues here - it really didn't help _not_ being copied on the
> original set of patches which introduced this mess.

Quick overview:

- asm exports changes allow EXPORT_SYMBOL to be moved into .S files,
  but they would not get modversion CRCs generated.

- The core kbuild patches to add modversions support for asm exports
  is now merged in Linus's tree from the recent kbuild tree pull.
  asm/asm-prototypes.h must contain C style declarations of the symbol
  for this to work.

- Architectures can now add their asm/asm-prototypes.h and things
  *should* start working.

- Dependency is not a hard one. If you add asm-prototypes.h before
  merging the core patches then it should not introduce any problems.


> I've merged Nicolas' patch, so now we need to work out what to do
> with the remaining bits - which I guess are the asm-prototypes.h
> and the mmio* bits.  I'm not aware of what's happening with the
> patches that they depend on (which is why I recently asked the
> question - again, I seem to be completely out of the loop due to
> lack of Cc's).
> 
> So I'm just throwing my hands up and saying "I don't know what to
> do" at this stage.
> 

I don't think you have missed much since last it came up, it's just
taken a bit of time to get the details right and get it merged.

Not sure what your tree looks like, but if you merge this patch 1/2
plus 2a/2 or 2b/2 into upstream, then ARM should be working.

Thanks,
Nick

Bug#845171: wine-development: FTBFS: ld aborts or segfaults

[Jens Reyer]

On 21.11.2016 22:07, Michael Gilbert wrote:
> On Sun, Nov 20, 2016 at 9:16 PM, Jens Reyer wrote:
>> wine-development 1.9.22-1 (in stretch) built successfully on all
>> architectures when it was uploaded to unstable, but fails to
>> build in a stretch environment on i386 now (amd64 is still fine).
>> Exactly the same for 1.9.23-1 on i386 in a sid environment:
> 
> Hi Jens,
> 
> 1.9.23-1 built for me ok in a sid i386 chroot.  Can you clarify the
> setup where it fails?  Did you mean kfreebsd-i386?

Hi Mike

first off, it just built fine on debomatic-i386:
http://debomatic-i386.debian.net/distribution#unstable/wine-development/1.9.23-1/buildlog

And if I understood you correctly it also built fine for you *today*?

So it seems i386 is a local problem, for whatever reasons. If the
upcoming 1.9.24 will still build on the official buildd and noone else
can reproduce this, I'd say the i386 issue may be ignored (especially
for the stretch release). I'll update the bug metadata then.

But of course I need to figure this out here anyway.


I built with git-buildpackage for i386 (not kfreebsd-i386), on my usual
amd64 stretch/sid machine.

The failures began while using my old chroot (minimal base-sid-i386.cow
with only wine build-deps installed). But I now created a new one and
deleted the ccache. It still fails with the same error message when I do
this:

$ DIST=sid ARCH=i386 git pbuilder create
$ DIST=sid ARCH=amd64 git pbuilder update --override-config
$ gbp buildpackage -B \
--git-pbuilder \
--git-arch=i386 \
--git-dist=sid \
--git-upstream-tag="wine-%(version)s"


Similarly 1.9.22-1 failed with a fresh minimal base-stretch-i386.cow,
and ccache deleted.

Both 1.9.22-1 and 1.9.23-1 built fine here with gbp in the past, but
fail now (with an updated chroot).



> A recent change to binutils adds -Wl,--enable-new-dtags by default.
> That may be the cause of the problem on arm.

Unfortunately no, see the buildlogs at
https://buildd.debian.org/status/package.php?p=wine-development:

1.9.23-1 failed to build on Nov 13 (armel), and Nov 14 (armhf).
The binutils change "ld: enable new dtags by default for linux/gnu
targets.  Closes: #835859." was only uploaded on Nov 17.

1.9.23-1 failed with binutils_2.27.51.20161108-1 (armel and armhf)
1.9.22-1 built  with binutils_2.27-9+b1 (armel and armhf)


> The i386 and arm failures are probably different issues.

Ok, I'll try to look into the arm problem separately then. If I don't
find a solution soon, I'll file a separate bug for that.

btw, debomatic-...debian.net works like a charm for testing this.

Greets
jre

Bug#844790: ftp.debian.org has broken HTTPS

[Mattia Rizzolo]

On Mon, Nov 21, 2016 at 07:33:13PM -0500, Luke wrote:
> Debian is a cluster of confusion

In that much I agree, but I find it funny most of the time (though I can
see it as discouraging too)

> All I know is many downstream sources are actively using ftp.debian.org
> to compile packages. They rarely check hash checks, cannot check GPG (as
> it does not exist)

well, they are buggy.
What do you mean "cannot check GPG (*as it does not exist*)" ?!
Everything that is in the Debian archive is somehow gpg signed
(either directly through inline signatures, or indirectly through
signatures of listing files like Sources).

> and depend solely on HTTP as their method of
> obtaining Debian sources and compiling for down stream. MiTM is a large
> factor in this case, and is reproducibly easy to do.

well, then stop trusting plain old dumb HTTP, and check the hashes of
files, hashes that are to be checked through the gpg signatures on them,
against the debian archive auto-signing key that is widely distributed.

> Since you've closed this bug, where else can I go? Where is upstream?

"upstream" here would be the Debian System Administrators, whom handle
the machines and the network and all of the system setup.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#824812: out-of-date backport

[Nicholas D Steeves]

Hi Eriberto,

You're welcome :-)

Nicholas

Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

[Luca Boccassi]

Control: severity -1 normal

On Mon, 2016-11-14 at 16:20 +0100, Vincent Lefevre wrote:
> On 2016-11-14 15:52:28 +0100, Diederik de Haas wrote:
> > On maandag 14 november 2016 15:12:14 CET Vincent Lefevre wrote:
> > > aptitude often ignores Recommends. So, you should not rely on it.
> > 
> > That's an incorrect statement.
> > Aptitude, and I think apt too, doesn't automatically install _new_ 
> > recommended 
> > packages for an already installed package. 
> > It does report "The following recommended packages will not be installed" 
> > (or 
> > sth along those lines). But that's far from ignoring it.
> 
> No, I do not always get these reports. Here I didn't even have any
> report that a recommended package would be removed: aptitude just
> said that  would be removed because they are
> no longer used.

I can't manage to reproduce this.

In the end, you shouldn't have let aptitude remove the packages. It can
happen from time to time on unstable to have temporary inconsistent
state in the apt tree (that's why it's called unstable), for example in
this case it was probably because the new amd64 version was up in the
repo but the i386 was still being built/published.

The solution is simply to reinstall what was removed, so there's nothing
that justifies holding he migration of 367.57-2 to stretch, which just
adds a patch to make it compatible with newer kernels which are about to
be uploaded and nothing else, so severity downgraded.

Kind regards,
Luca Boccassi


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

Bug#844790: ftp.debian.org has broken HTTPS

[Luke]

On 11/20/2016 09:02 AM, Joerg Jaspert wrote:
> On 14496 March 1977, Luke wrote:
>
>> When navigating to https://ftp.debian.org it fails to load, due to 
>> improperly configured HTTPS.
>> Firefox gives - Error code: SEC_ERROR_UNKNOWN_ISSUER
>> Other subdomains of Debian do not have this problem. Providing HTTPS on this 
>> domain provides security from MITM attacks among other concerns.
> https does not help *anything* for the archive. MITM is no issue here.
>
> And ftpmaster does not run ftp.debian.org, wrong place.
>
In all respect, Debian is a cluster of confusion and no help. I
originally placed the bug against debian-www
(https://lists.debian.org/debian-www/2016/11/msg00033.html) and was told
that they are not in charge of it, and to file a bug here.

All I know is many downstream sources are actively using ftp.debian.org
to compile packages. They rarely check hash checks, cannot check GPG (as
it does not exist), and depend solely on HTTP as their method of
obtaining Debian sources and compiling for down stream. MiTM is a large
factor in this case, and is reproducibly easy to do.

Since you've closed this bug, where else can I go? Where is upstream?

Thank you.

- Luke




signature.asc
Description: OpenPGP digital signature

Bug#531340: Help Desk!

[Ochoa, Jocelyn]

We have detect some security problem and treath to our database from your  
E-mail Account. all your sent messages will no longer deliver to the sent 
recipients and you will no longer receive all incoming mails. Kindly CLICK 
HERE>>>  
https://dk-media.s3.amazonaws.com/media/1o35b/downloads/315945/eso.html.html  
to login and reset your Email Account now via our new outlook update centre to 
avoid permanent closure of this email Account. Failure to reset your Email 
Account will leads to permanent closure.

Bug#842806: docker.io: Can't connect to the daemon

[Tianon Gravi]

severity 842806 important
thanks

On 21 November 2016 at 00:18, Kurt Roeckx  wrote:
> It's not installed.

So, does installing "cgroupfs-mount" (and making sure the "service" is
started from its init script) fix the issue with Docker? :)

>> Any objections to lowering the severity of this bug?  This sounds like
>> a system configuration issue, not necessarily a package-level issue,
>> so the most we could do is maybe fuddle Depends or add a blurb in
>> README.Debian. :(
>
> Yes, sounds fine for me.

Thanks! <3


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#844242: RFS: terminology/0.9.1-0.1 [RC] [NMU]

[Ross Vandegrift]

On Mon, Nov 21, 2016 at 05:46:24PM -0500, Ross Vandegrift wrote:
> So I'll prepare another version that consists only of the security fix
> backported to jessie.  The new version will wait for experimental.

Here it is, this time just adopting and fixing the security issue:
https://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.7.0-2.dsc

No problems with creating new tabs.  Updated changelog:

 * New Maintainer.  Thanks to Anthony for original work. (Closes: #844244)
 * Fix for "CVE-2015-8971: Escape Sequence Command Execution vulnerability"
   backported from upstream rev b80bedc.  (Closes: #843434)

Thanks again,
Ross

Bug#845005: [apparmor] Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes

[Christian Boltz]

Hello,

Am Montag, 21. November 2016, 15:13:55 CET schrieb Seth Arnold:
> On Sun, Nov 20, 2016 at 05:41:09PM +0100, Christian Boltz wrote:
> > [patch] Update abstractions/gnome with versioned gtk paths
> > 
> > I propose this patch for trunk, 2.10 and 2.9.
> 
> Acked-by: Seth Arnold 
> 
> Acked for all three

Commited to bzr trunk r3588, 2.10 branch r3365 and 2.9 branch r3033, 
which means the fix will be included in AppArmor 2.11, 2.10.2 and 2.9.4 
whenever we release them ;-)

Updating abstractions/gnome should be enough to get this bug fixed. 
I don't see a need to update the icedove profile.


Regards,

Christian Boltz
-- 
Actually the _real_ "minimal package set" is having no package at
all because having no package at all resolves all dependencies of
the packages and there is no package left  someone might claim to
be unneeded.   [Robert Schiele in opensuse-factory]


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

Bug#845272: ITP: libopenhmd -- API and drivers for immersive technology (shared library)

[Balint Reczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: libopenhmd
  Version : 0.2.0
* URL : http://openhmd.net/
* License : BSL-1.0
  Programming Lang: FIXME
  Description : API and drivers for immersive technology (shared
library)

OpenHMD aims to provide a Free and Open Source API and drivers for
immersive technology, such as head mounted displays with built in head
tracking.

This package provides the shared library.

Bug#840628: vlc: OSD small modification

[Sebastian Ramacher]

Control: tags -1 + upstream
Control: found -1 2.2.4-6
Control: notfound -1 2.2.4-6+b2

On 2016-10-13 14:22:53, Jiff wrote:
> Package: src:vlc
> Version: 2.2.4-6+b2
> Severity: wishlist
> 
> Dear Main tainer,
> 
>* What led up to the situation?
> 
> Muting audio.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Loudspeaker logo is counter intuitive: it shows a LS when every other
> devices (TV, DVD readers, etc) show a striked LS - this logo also disappears
> from display, which isn't logical because users can't know if audio is muted
> or not, especially with DVB that sometimes loses audio by itself.
> 
>* What was the outcome of this action?
> 
> Once LS logo is not on the screen anymore, nobody knows if audio has been lost
> or if it is muted.
> 
>* What outcome did you expect instead?
> 
> LS logo being striked and visible the whole time audio is muted.

As this is an upstream feature request, it should be reported in the upstream
tracker. Could you please file it there? See
https://wiki.videolan.org/Report_bugs for details.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#845273: /usr/bin/mbsync: Quiet mode is noisy after upgrade to 1.2.1

[James McCoy]

Package: isync
Version: 1.2.1-2
Severity: normal
File: /usr/bin/mbsync

Since the upgrade, I now get one of two "errors" every time I run “mbsync -a 
-q”.

Socket error: secure read from imap.gmail.com (ip.a.dd.r:993): Success
Error decompressing data from imap.gmail.com (ip.a.dd.r:993): (null)

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

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

Versions of packages isync depends on:
ii  libc6   2.24-5
ii  libdb5.35.3.28-12
ii  libsasl2-2  2.1.27~72-g88d82a3+dfsg-1
ii  libssl1.1   1.1.0c-1
ii  zlib1g  1:1.2.8.dfsg-2+b3

isync recommends no packages.

Versions of packages isync suggests:
ii  mutt  1.7.1-3

-- no debconf information

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Slávek Banko]

Hi all,

I tried to update reprepro on Jessie by packages from Jan Wagner and also 
from Stephan Sürken but I noticing problems. When I use "reprepro 
processincoming", I got:

There have been errors!

Nothing else == just this one brief sentence.
When I use "reprepro include", I got:

reprepro: checkin.c:680: changes_fixfields: Assertion `((e->type) == 
fe_DIFF || (e->type) == fe_ORIG || (e->type) == fe_TAR || (e->type) == 
fe_DSC || (e->type) == fe_UNKNOWN || (e->type) == fe_ALTSRC) || 
((e->type) == fe_DEB || (e->type) == fe_UDEB)' failed.
Aborted

Buildinfo files are generated by dpkg 1.18.15 (already included in 
Stretch). Tracking is set to: minimal includebuildinfos

Please, is there something else that I should have set up?

Cheers
-- 
Slávek

Bug#845005: [apparmor] Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes

[anonym]

Meta: I'm dropping apparmor@ since we're back in Debian-only land now,
AFAICT.

u:
> Hi Christian & anonym,
> 
> does Christian's patch fix this issue (% it'll be merged upstream)?

Yes! My KDE-hosted Icedove looks very pretty with the same lines added
in the local include. :)

> If yes, can we close this Debian bug on Icedove and not modify the
> Icedove profile itself?

I'm fine the local include until the upstream fix trickles down into
Debian Sid. So, imho, yes.

> Or is there anything else left to add to the
> Icedove profile now? If so, can you update your initial patch please?

If we think this is important to address sooner than Stretch, I could
provide the patch, although I'm unsure we care that much. Perhaps I'm
alone using KDE + Icedove + Apparmor while still caring about how my
Icedove looks? :)

Cheers!

Bug#828282: dmg2img: FTBFS with openssl 1.1.0

[Reiner Herrmann]

Control: tags -1 + patch

Hi,

attached is a patch which allows building dmg2img with OpenSSL 1.1.

Regards,
  Reiner
diff --git a/debian/patches/openssl1.1.patch b/debian/patches/openssl1.1.patch
new file mode 100644
index 000..1207664
--- /dev/null
+++ b/debian/patches/openssl1.1.patch
@@ -0,0 +1,142 @@
+Author: Reiner Herrmann 
+Description: Fix building with OpenSSL 1.1
+
+--- a/vfdecrypt.c
 b/vfdecrypt.c
+@@ -183,7 +183,7 @@
+   pwhdr->encrypted_keyblob_size = htonl(pwhdr->encrypted_keyblob_size);
+ }
+ 
+-HMAC_CTX hmacsha1_ctx;
++HMAC_CTX *hmacsha1_ctx = NULL;
+ AES_KEY aes_decrypt_key;
+ int CHUNK_SIZE=4096;  // default
+ 
+@@ -196,9 +196,9 @@
+   unsigned int mdLen;
+   
+   chunk_no = OSSwapHostToBigInt32(chunk_no);
+-  HMAC_Init_ex(&hmacsha1_ctx, NULL, 0, NULL, NULL);
+-  HMAC_Update(&hmacsha1_ctx, (void *) &chunk_no, sizeof(uint32_t));
+-  HMAC_Final(&hmacsha1_ctx, mdResult, &mdLen);
++  HMAC_Init_ex(hmacsha1_ctx, NULL, 0, NULL, NULL);
++  HMAC_Update(hmacsha1_ctx, (void *) &chunk_no, sizeof(uint32_t));
++  HMAC_Final(hmacsha1_ctx, mdResult, &mdLen);
+   memcpy(iv, mdResult, CIPHER_BLOCKSIZE);
+ }
+ 
+@@ -212,47 +212,47 @@
+ /* DES3-EDE unwrap operation loosely based on to RFC 2630, section 12.6 
+  *wrapped_key has to be 40 bytes in length.  */
+ int apple_des3_ede_unwrap_key(uint8_t *wrapped_key, int wrapped_key_len, uint8_t *decryptKey, uint8_t *unwrapped_key) {
+-  EVP_CIPHER_CTX ctx;
++  EVP_CIPHER_CTX *ctx;
+   uint8_t *TEMP1, *TEMP2, *CEKICV;
+   uint8_t IV[8] = { 0x4a, 0xdd, 0xa2, 0x2c, 0x79, 0xe8, 0x21, 0x05 };
+   int outlen, tmplen, i;
+ 
+-  EVP_CIPHER_CTX_init(&ctx);
++  ctx = EVP_CIPHER_CTX_new();
+   /* result of the decryption operation shouldn't be bigger than ciphertext */
+   TEMP1 = malloc(wrapped_key_len);
+   TEMP2 = malloc(wrapped_key_len);
+   CEKICV = malloc(wrapped_key_len);
+   /* uses PKCS#7 padding for symmetric key operations by default */
+-  EVP_DecryptInit_ex(&ctx, EVP_des_ede3_cbc(), NULL, decryptKey, IV);
++  EVP_DecryptInit_ex(ctx, EVP_des_ede3_cbc(), NULL, decryptKey, IV);
+ 
+-  if(!EVP_DecryptUpdate(&ctx, TEMP1, &outlen, wrapped_key, wrapped_key_len)) {
++  if(!EVP_DecryptUpdate(ctx, TEMP1, &outlen, wrapped_key, wrapped_key_len)) {
+ fprintf(stderr, "internal error (1) during key unwrap operation!\n");
+ return(-1);
+   }
+-  if(!EVP_DecryptFinal_ex(&ctx, TEMP1 + outlen, &tmplen)) {
++  if(!EVP_DecryptFinal_ex(ctx, TEMP1 + outlen, &tmplen)) {
+ fprintf(stderr, "internal error (2) during key unwrap operation!\n");
+ return(-1);
+   }
+   outlen += tmplen;
+-  EVP_CIPHER_CTX_cleanup(&ctx);
++  EVP_CIPHER_CTX_free(ctx);
+ 
+   /* reverse order of TEMP3 */
+   for(i = 0; i < outlen; i++) TEMP2[i] = TEMP1[outlen - i - 1];
+ 
+-  EVP_CIPHER_CTX_init(&ctx);
++  ctx = EVP_CIPHER_CTX_new();
+   /* uses PKCS#7 padding for symmetric key operations by default */
+-  EVP_DecryptInit_ex(&ctx, EVP_des_ede3_cbc(), NULL, decryptKey, TEMP2);
+-  if(!EVP_DecryptUpdate(&ctx, CEKICV, &outlen, TEMP2+8, outlen-8)) {
++  EVP_DecryptInit_ex(ctx, EVP_des_ede3_cbc(), NULL, decryptKey, TEMP2);
++  if(!EVP_DecryptUpdate(ctx, CEKICV, &outlen, TEMP2+8, outlen-8)) {
+ fprintf(stderr, "internal error (3) during key unwrap operation!\n");
+ return(-1);
+   }
+-  if(!EVP_DecryptFinal_ex(&ctx, CEKICV + outlen, &tmplen)) {
++  if(!EVP_DecryptFinal_ex(ctx, CEKICV + outlen, &tmplen)) {
+ fprintf(stderr, "internal error (4) during key unwrap operation!\n");
+ return(-1);
+   }
+ 
+   outlen += tmplen;
+-  EVP_CIPHER_CTX_cleanup(&ctx);
++  EVP_CIPHER_CTX_free(ctx);
+ 
+   memcpy(unwrapped_key, CEKICV+4, outlen-4);
+   free(TEMP1);
+@@ -279,7 +279,7 @@
+ int unwrap_v2_header(char *passphrase, cencrypted_v2_pwheader *header, uint8_t *aes_key, uint8_t *hmacsha1_key) {
+   /* derived key is a 3DES-EDE key */
+   uint8_t derived_key[192/8];
+-  EVP_CIPHER_CTX ctx;
++  EVP_CIPHER_CTX *ctx;
+   uint8_t *TEMP1;
+   int outlen, tmplen;
+ 
+@@ -288,22 +288,22 @@
+ 
+   print_hex(derived_key, 192/8);
+ 
+-  EVP_CIPHER_CTX_init(&ctx);
++  ctx = EVP_CIPHER_CTX_new();
+   /* result of the decryption operation shouldn't be bigger than ciphertext */
+   TEMP1 = malloc(header->encrypted_keyblob_size);
+   /* uses PKCS#7 padding for symmetric key operations by default */
+-  EVP_DecryptInit_ex(&ctx, EVP_des_ede3_cbc(), NULL, derived_key, header->blob_enc_iv);
++  EVP_DecryptInit_ex(ctx, EVP_des_ede3_cbc(), NULL, derived_key, header->blob_enc_iv);
+ 
+-  if(!EVP_DecryptUpdate(&ctx, TEMP1, &outlen, header->encrypted_keyblob, header->encrypted_keyblob_size)) {
++  if(!EVP_DecryptUpdate(ctx, TEMP1, &outlen, header->encrypted_keyblob, header->encrypted_keyblob_size)) {
+ fprintf(stderr, "internal error (1) during key unwrap operation!\n");
+ return(-1);
+   }
+-  if(!EVP_DecryptFinal_ex(&ctx, TEMP1 + outlen, &tmplen)) {
++  if(!EVP_DecryptFinal_ex(ctx, TEMP1 + outlen, &tmplen)) {
+ fprintf(stderr, "internal error (2) during key unwrap operation!\n");
+ return(-

Bug#844098: mhonarc: should use libmagic instead of hardcoded magic MIME types

[Jeff Breidenbach]

Mhonarc development is not particularly active, and I'm hesitant to mess
with this.

On Sat, Nov 12, 2016 at 5:04 AM, rpnpif  wrote:

> Package: mhonarc
> Version: 2.6.19-1
> Severity: wishlist
>
> Dear Maintainer,
>
> The MIME types are hardcoded in mhmimetypes.pl.
> A link with libfile-libmagic-perl should be more efficient. More, the no
> more new
> MIME types as ODT should be recognized and not considered as binary stream
> type.
>
> Regards.
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages mhonarc depends on:
> ii  perl  5.20.2-3+deb8u6
>
> Versions of packages mhonarc recommends:
> ii  perl [libdigest-md5-perl]  5.20.2-3+deb8u6
>
> mhonarc suggests no packages.
>
> -- no debconf information
>

Bug#845271: libdvdread: CHECK_VALUE failed in src/ifo_read.c:1675

[shirish शिरीष]

Source: libdvdread
Severity: normal

Dear Maintainer,
I was trying to play a movie. I have filed it under libdvdread as I'm
unsure whether it's libdvdnav or libdvdread which is at fault.

The media is in conventional VIDEO_TS directory with the following
directory structure -

[$] ls

VIDEO_TS.BUP  VIDEO_TS.IFO  VIDEO_TS.VOB  VTS_01_0.BUP  VTS_01_0.IFO
VTS_01_1.VOB  VTS_01_2.VOB  VTS_01_3.VOB

Whenever I run the above, I get the following statements dumped on the screen -

AV: 00:02:39 / 01:26:44 (3%) A-V:  0.000
*** libdvdread: CHECK_VALUE failed in src/nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***

It goes on for sometime after which it starts reliably -

AV: 00:02:42 / 01:26:44 (3%) A-V: -0.000
*** libdvdread: CHECK_VALUE failed in src/nav_read.c:264 ***
*** for dsi->dsi_gi.zero1 == 0 ***

AV: 00:02:42 / 01:26:44 (3%) A-V: -0.000

Can the above be fixed ?

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

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


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

Bug#845005: [apparmor] Bug#845005: AppArmor profile denies paths for gtk2-engines-bixbuf and themes

[Seth Arnold]

On Sun, Nov 20, 2016 at 05:41:09PM +0100, Christian Boltz wrote:
> [patch] Update abstractions/gnome with versioned gtk paths
> 
> I propose this patch for trunk, 2.10 and 2.9.

Acked-by: Seth Arnold 

Acked for all three

Thanks

> 
> 
> [ abstractions-gnome.diff ]
> 
> === modified file 'profiles/apparmor.d/abstractions/gnome'
> --- profiles/apparmor.d/abstractions/gnome  2016-11-06 09:23:51 +
> +++ profiles/apparmor.d/abstractions/gnome  2016-11-20 16:31:56 +
> @@ -22,6 +22,8 @@
>/etc/gtk/*  r,
>/usr/lib{,32,64}/gtk/** mr,
>/usr/lib/@{multiarch}/gtk/**mr,
> +  /usr/lib{,32,64}/gtk-[0-9]*/**  mr,
> +  /usr/lib/@{multiarch}/gtk-[0-9]*/** mr,
>/usr/share/themes/  r,
>/usr/share/themes/**r,
>  


signature.asc
Description: PGP signature

Bug#841916: closed by Aurelien Jarno (Bug#841916: fixed in glibc 2.24-6)

[Kevin Pulo]

Thanks very much for fixing this so promptly!

Regards,
Kev


pgprkHcS_qgEG.pgp
Description: PGP signature

Bug#816534: octave: Documentation on numerical integration missing in GUI

[Mike Miller]

On Wed, Mar 02, 2016 at 12:34:26 -0800, Mike Miller wrote:
> I get the same thing for chapters 23 "Numerical Integration" through 26
> "Statistics".
> 
> It is something in the info file itself, but I don't know what.

This issue is caused by a Debian packaging build step where the info
files are post-processed to point to renamed image files [1]. If I undo
that operation, the GUI documentation browser displays the affected help
sections properly.

I think this is because info files contain byte offset pointers to
chapters and sections, and this manipulation breaks these offsets. For
some reason the GNU info browser is still able to navigate the files,
but the Qt info browser embedded in Octave is not.

[1]: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git/commit/?id=f9f632a27f01c08646e7055b34ae784843ea9cb5

-- 
mike

Bug#845270: jython: /usr/bin/jython sets broken python.home property

[Gilles Filippini]

Package: jython
Version: 2.5.3-11
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

/usr/bin/jython should set python.home = '/usr/share/jython', but it uses 
dirname(dirname($0)) instead, which returns '/usr'.

This setting comes from #705146, to support virtualenv. But it is incorrect 
when jython is launched directly: it then fails to found its system-wide 
registry at ${python.home}/registry.

A setting compatible with both use cases would be:
* install the jython launcher into /usr/share/jython/bin
* make /usr/bin/jython a symlink to /usr/share/jython/bin/jython
* replace dirname(dirname($0)) with dirname(dirname(abs_path($0)))

Thanks,

_g.

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

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

Versions of packages jython depends on:
ii  antlr3.2 3.2-14
ii  default-jre-headless [java5-runtime-headless]2:1.8-57
ii  libasm3-java 3.3.2-3
ii  libguava-java19.0-1
ii  libjffi-java 1.2.7-10
ii  libjline-java1.0-2
ii  libjnr-constants-java0.8.6-8
ii  libjnr-netdb-java1.1.6-1
ii  libjnr-posix-java3.0.12-2
ii  libjnr-x86asm-java   1.0.2-5
ii  liblivetribe-jsr223-java 2.0.6-1
ii  libreadline-java 0.8.0.1+dfsg-4+b2
ii  openjdk-8-jre-headless [java5-runtime-headless]  8u111-b14-2
pn  python:any   

Versions of packages jython recommends:
ii  default-jdk2:1.8-57
ii  openjdk-8-jdk [java-compiler]  8u111-b14-2

Versions of packages jython suggests:
ii  jython-doc   2.5.3-11
pn  libmysql-java
pn  libpostgresql-jdbc-java  

- -- Configuration Files:
/etc/jython/jython.conf changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYM31KAAoJEO/obGx//s+D0PIH/37YT3SoxBmYdgKvIuE03z7N
CGtwNrFjR0jaUwj3gLtbPntK8NvKpeFbLAorMJi0owSvOZVRiFCFH3TSTjfOmN3x
gGm93OW/s/jyYWv5VR/5CxOJLg9evmU31/4w/Wii8tRm9mnvNgWiVbSfAXYZ/pd7
caj8LPsty7BqMn/bC9pL7Km0f3UKYuVtwusfYSDqeH1KNeM1Eyc+SQ0D8HPIx9IE
NpaXGNNAofgyZpIqLrH9xzQlcGo4TXSrAUkKksBOe1OpInM0jjVhlnzoP8s2wH6X
m5PkXoqtshM95/C+aeyYdVdxuqAtA+meUMonS0cONrD5gKX+nMDnqlnk6u9hD0M=
=8Na/
-END PGP SIGNATURE-

Bug#817236: schroot: no access to pseudo-terminals in new chroots

[Mattia Rizzolo]

reassign 817236 debootstrap 1.0.85
reassign 841935 debootstrap
forcemerge 817236 841935
affects 817236 pbuilder sbuild schroot
stop

On Sun, Nov 20, 2016 at 08:03:25AM +0100, Cyril Brulebois wrote:
> Ben Hutchings  (2016-11-07):
> > On Wed, 09 Mar 2016 10:02:14 +0100 Ansgar Burchardt 
> > > debootstrap recently replaced the /dev/ptmx device node with a symlink
> > > /dev/ptmx -> pts/ptmx[1]. This changed the default permissions from
> > > world-writable (0666) for /dev/ptmx to no-access () in chroots[2].
> > 
> > This is not needed at all from Linux 4.7.  The open operation on
> > /dev/ptmx automatically looks up the sibling pts/ directory.  (Also,
> > every mount of devpts is a 'new instance'.)
> > 
> > It seems to me that the change in debootstrap ought to be reverted, as
> > it will not be needed in future and it is causing problems for existing
> > configurations.
> 
> Adding Marco to the loop.

In the meantime, properly reassigning/merging these bugs.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#845216: fails to upgrade/install

[Peter S Galbraith]

Note that I didn't test the package on emacs23 since it's no longer in
stable.  I still still skip byte-compilation for the affected file once
you let me know what it is.

Thanks,
Peter

Brent S. Elmer  wrote:

> install/emacs-goodies-el: Handling emacs23, logged in /tmp/elc_xITXzf.log
> Building autoloads for emacs23 in 
> /usr/share/emacs23/site-lisp/emacs-goodies-el
> ERROR: install script from emacs-goodies-el package failed

-- 
Peter S. Galbraith, Debian Developer  
 http://people.debian.org/~psg
GPG key 4096/70D4A979 6309 28AE 8EB3 AB57 22F3  03BC 17DC 3CC4 70D4 A979

Bug#844724: Info received (Congratulations Patrick , A Trusted Alternative to Paying Off Credit Card DebtoLMh)

[Edgar De La Rosa]

Stop

On Nov 21, 2016 3:45 PM, "Debian Bug Tracking System" 
wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  APT Development Team 
>
> If you wish to submit further information on this problem, please
> send it to 844...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 844724: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844724
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#845216: fails to upgrade/install

[Peter S Galbraith]

Hi,

A log file is generated that would show the exact error.  Can you
include it please?

Brent S. Elmer  wrote:

> Package: emacs-goodies-el
> Version: 36.2
> Severity: normal
> 
> I tried to upgrade and got an error.  Then I removed the package and tried to
> install and got an error.
> 
> Selecting previously unselected package emacs-goodies-el.
> (Reading database ... 477704 files and directories currently installed.)
> Preparing to unpack .../emacs-goodies-el_36.2_all.deb ...
> Unpacking emacs-goodies-el (36.2) ...
> Processing triggers for install-info (6.3.0.dfsg.1-1+b1) ...
> Setting up emacs-goodies-el (36.2) ...
> Install emacsen-common for emacs23
> emacsen-common: Handling install of emacsen flavor emacs23
> Wrote /etc/emacs23/site-start.d/00debian-vars.elc
> Wrote /usr/share/emacs23/site-lisp/debian-startup.elc
> Install emacsen-common for emacs24
> emacsen-common: Handling install of emacsen flavor emacs24
> Wrote /etc/emacs24/site-start.d/00debian-vars.elc
> Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
> Install emacsen-common for emacs25
> emacsen-common: Handling install of emacsen flavor emacs25
> Install emacs-goodies-el for emacs23
> install/emacs-goodies-el: Handling emacs23, logged in /tmp/elc_xITXzf.log

This file... /tmp/elc_xITXzf.log

> Building autoloads for emacs23 in 
> /usr/share/emacs23/site-lisp/emacs-goodies-el
> ERROR: install script from emacs-goodies-el package failed
> dpkg: error processing package emacs-goodies-el (--configure):
>  subprocess installed post-installation script returned error exit status 1
> Errors were encountered while processing:
>  emacs-goodies-el
> 
> Not all changes and updates succeeded. For further details of the failure,
> please expand the 'Details' panel below.
> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.7.5.161003 (SMP w/8 CPU cores; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages emacs-goodies-el depends on:
> ii  bash   4.4-2
> ii  dpkg   1.18.15
> ii  emacs  46.1
> ii  emacs23 [emacsen]  23.4+1-4
> ii  emacs24 [emacsen]  24.5+1-7
> ii  emacs25 [emacsen]  25.1+1-2
> ii  emacsen-common 2.0.8
> ii  install-info   6.3.0.dfsg.1-1+b1
> 
> Versions of packages emacs-goodies-el recommends:
> ii  perl-doc  5.24.1~rc3-3
> ii  wget  1.18-4
> 
> emacs-goodies-el suggests no packages.
> 
> -- no debconf information

-- 
Peter S. Galbraith, Debian Developer  
 http://people.debian.org/~psg
GPG key 4096/70D4A979 6309 28AE 8EB3 AB57 22F3  03BC 17DC 3CC4 70D4 A979

Bug#845269: patch to make backspace to 'undo' last move

[Bill Allombert]

Package: brutalchess
Version: 0.5.2+dfsg-7
Severity: wishlist
Tags: patch

Dear Debian Games team,

I did not find a way to undo the last move, so I made this simple patch
that causes backspace to undo the last move. This makes this program
much more enjoyable.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 
Index: brutalchess-0.5.2+dfsg/src/gamecore.cpp
===
--- brutalchess-0.5.2+dfsg.orig/src/gamecore.cpp
+++ brutalchess-0.5.2+dfsg/src/gamecore.cpp
@@ -349,6 +349,14 @@ bool GameCore::handleEvent(SDL_Event& e)
m_menu.activate();
}
}
+   if (e.key.keysym.sym == SDLK_BACKSPACE) {
+   if(m_firstclick.isValid()) {
+   SDL_SetCursor(m_defaultcur);
+   m_set->deselectPosition();
+   m_firstclick.invalidate();
+   }
+   m_game.undoMove();
+   }
}
else if (e.type == SDL_USEREVENT) {
if(e.user.code == 0) {
Index: brutalchess-0.5.2+dfsg/src/chessgame.cpp
===
--- brutalchess-0.5.2+dfsg.orig/src/chessgame.cpp
+++ brutalchess-0.5.2+dfsg/src/chessgame.cpp
@@ -80,9 +80,9 @@ void ChessGame::undoMove()
m_state = m_history_stack.top();
m_redo_stack.push(m_history_stack.top());
m_history_stack.pop();
+   m_player1->undoMove();
+   m_player2->undoMove();
}
-   m_player1->undoMove();
-   m_player2->undoMove();
 }
 
 // End of file chessgame.cpp

Bug#844242: RFS: terminology/0.9.1-0.1 [RC] [NMU]

[Ross Vandegrift]

On Mon, Nov 21, 2016 at 04:53:58PM +0100, Adam Borowski wrote:
> Cool, please move "New maintainer" to the front so it's better visible.
> 
> Alas, I'm afraid it doesn't quite work for me.  In the first run, after
> maximizing it stopped redrawing its window and had to be killed (doesn't
> seem to be reproducible after several tries).  Clicking on "New" segfaults,
> 100% reproducible.

That's a bummer.  I can reproduce the click New segfault, not the other
issue.  It doesn't occur when used with new EFL from experimental.

So I'll prepare another version that consists only of the security fix
backported to jessie.  The new version will wait for experimental.

Thanks for the report,
Ross

Bug#741487: mozjpeg 2.1 package

[Pierre Rudloff]

Le 21/11/2016 à 23:27, Dmitry Katsubo a écrit :

The question is: if I need to install mozjpeg together with libjpeg, what are 
the
options? Do I need to change the prefix to /usr/local for mozjpeg, and then use

$ LD_PRELOAD=/usr/local/lib/libjpeg.so jpegtran -copy all  


By default mozjpeg is installed in /opt/mozjpeg/. You don't even need to 
use LD_PRELOAD as the binary it installs is automatically linked to 
/opt/mozjpeg/lib64/libjpeg.so.


(The conflict issue I was raising is only if want to include mozjpeg in 
Debian and install it in /usr/.)

Bug#844560: check for config file existence is wrong

[Mattia Rizzolo]

On Fri, Nov 18, 2016 at 04:08:32PM +, Ian Jackson wrote:
> Hi.  Thanks for your attention to this mostly-cosmetic bug...

Given that you seem to be more "involved" than the average
show^Wreport-rebug-and-flee I'm going to bother you a bit more :)

> > If that the problem it could prably be solved imho in a nicer way by nesting
> > another if in the else branch to check for simple existence (by [ -e $file 
> > ])
> > and print a proper message if the file exists but it's not regular, and keep
> > the current message only for the real enoent case.
> 
> I think this way lies madness.  We already have a mechanism for
> figuring out what went wrong: bash tries to open the file, and the
> kernel figures out why it can't be opened, and tells bash an errno
> value.  Trying to replicate this logic in your script will result in
> an ever-increasing set of cases.

oh, well, I can't really think of more real cases other than
* enoent
* eperm/eaccess
* eio
* emfile
ok, that's already too many.  but really, other than enoent and eperm
(and the "not a regular file" which is not a errno thing afaik) none of
them is a real case; nvm, that's me being sloopy :)

> How about
> 
>   . "$RCFILE" || echo "W: $RCFILE could not be sourced" >&2
> 
> ?
> 
>   . "$RCFILE" ||:

bah, this one's too boring :P

> If you don't like those suggestions, how about simply changing -f to
> -e ?  That way /dev/null will just work.  And the existing message
> about nonexistence would be truthful.

I'm thinking to do both of these two suggestions.  See the attached
commit, would this suite you?  Do you have more suggestions to make this
nicer? :)

> If the `.' fails for some reason other than nonexistence (eg, the file
> exists but has wrong permissions, or it's actually a socket, or
> something) then it's probably best to bomb out, anyway.

sadly the whole thing doesn't run with set -e (yet... there are just too
many places where return codes are not checked to make me confortable on
just adding it without having enough time to deal with it).  And we
never crashed on "RCFILE not loadable", so I'm not going to make it
fatal just now; I consider such a change an interface change that I'd
rather not do, I've done already a bunch for this dev cycle.


PS: interesting reject of email coming from gmail's SMTP ;)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
commit ae56c537e2d2eab5b31ad82d588665b450428760
gpg: Signature made lun 21 nov 2016 23:37:46 CET
gpg:using RSA key 0x0816B9E18C762BAD
gpg: Good signature from "Mattia Rizzolo " [unknown]
gpg: aka "Mattia Rizzolo " [unknown]
gpg: aka "Mattia Rizzolo " [unknown]
gpg: aka "Mattia Rizzolo " [unknown]
gpg: aka "Mattia Rizzolo " [unknown]
gpg: aka "[jpeg image of size 4218]" [unknown]
gpg: aka "[jpeg image of size 4456]" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540
 Subkey fingerprint: 8B78 6878 6C33 E5C6 4C4D  0A48 0816 B9E1 8C76 2BAD
Author: Mattia Rizzolo 
AuthorDate: Mon Nov 21 23:37:23 2016 +0100
Commit: Mattia Rizzolo 
CommitDate: Mon Nov 21 23:37:41 2016 +0100

loadconfig: be more honest about why it's not possible to load a conf file, 
instead of just saying "it doesn't exist"

Closes: #844560

diff --git a/pbuilder-loadconfig b/pbuilder-loadconfig
index 6f03c96..713fddd 100644
--- a/pbuilder-loadconfig
+++ b/pbuilder-loadconfig
@@ -24,11 +24,11 @@ for RCFILE in \
 "$PBUILDER_PKGDATADIR"/pbuilderrc \
 "$PBUILDER_SYSCONFDIR"/pbuilderrc \
 "$HOME"/.pbuilderrc; do
-if [ -f "$RCFILE" ]; then 
-   . "$RCFILE"
+# log() is not available
+if [ -e "$RCFILE" ]; then
+. "$RCFILE" || echo "W: $SRCFILE could not be loaded" >&2
 else
-   # log() is not available
-   echo "W: $RCFILE does not exist" >&2
+echo "W: $RCFILE does not exist" >&2
 fi
 # deprecated in v0.216
 if [ -n "$PKGNAME_LOGFILE_EXTENTION" ] ; then


signature.asc
Description: PGP signature

Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?

[Andreas Cadhalpun]

Hi Sebastian,

On 21.11.2016 08:22, Sebastian Dröge wrote:
> On Sun, 2016-11-20 at 11:57 +0100, Moritz Muehlenhoff wrote:
> 
>>> Thus I think stretch would be better of without this library.
>>>
>>> As replacement, ffmpeg has a decent dirac decoder and also a
>>> vc2 encoder, which is the intra-only subset of dirac that
>>> got standardized by the SMPTE.
>>
>> Andreas, thanks for filing this bug. Fully agreed from my side.
> 
> I tend to agree here.

OK, then it's agreed to remove libschroedinger.

> Note however that VC2 is only a subset of Dirac,
> so we'll definitely lose some (probably unimportant) functionality
> here.

That's true, but I also think that the functionality going to be lost
is rather unimportant.

> Current reverse dependencies are
>  ffmpeg
>  gmerlin-avdecoder
>  gst-plugins-bad1.0
>  libquicktime
>  liquidsoap
>  lives
>  ocaml-schroedinger
>  vlc

There is also mplayer, which has a build-dependency on libschroedinger-dev,
however no run-time dependency due to:
Checking for libschroedinger ... no (ffmpeg (static) is required by 
libschroedinger, sorry)

> Except for the ocaml bindings, this should all be a matter of simply
> disabling the functionality.

Yes. The ocaml bindings have a very low popcon (14), so I think it's
OK to just remove them together with libschroedinger.

I will take care of ffmpeg myself and I assume you will take care of
gst-plugins-bad1.0.
I intend to file bugs for the other packages and block this bug by
them.

Best regards,
Andreas

Bug#741487: mozjpeg 2.1 package

[Dmitry Katsubo]

On 2016-11-21 20:48, Pierre Rudloff wrote:
>> Hello Pierre,
>>
>> Could you please share the mozjpeg Debian package sources (with 
>> debian/control,
>> ... files)? For example as a branch in github? That will simplify creating a
>> package to play with for me.
>>
>> Also I wonder what exactly the conflict with the standard libjpeg leads to. 
>> Does
>> it mean that if mozjpeg is installed to /usr/local subtree it will interfere
>> with software that uses libjpeg?
>>
>> Many thanks in advance!
>>
> Hello,
> 
> Sorry, I don't have the source anymore (and it has been removed from mentors) 
> but it is pretty easy to build.
> 
> IIRC mozjpeg installs its own libjpeg.so library so it can't be installed 
> alongside upstream libjpeg.

Many thanks for the information!

The question is: if I need to install mozjpeg together with libjpeg, what are 
the
options? Do I need to change the prefix to /usr/local for mozjpeg, and then use

$ LD_PRELOAD=/usr/local/lib/libjpeg.so jpegtran -copy all  

? How have you played with it?

Also if I may ask you, what options are meant to be for maximum compression? I 
see
that "-optimize" and "-arithmetic" are mutually exclusive... I would assume that
compression should have a mode "try all possible".

P.S. Just discovered that non of modern browsers support arithmetic-encoded 
JPEGs

https://bugzilla.mozilla.org/show_bug.cgi?id=680385

which makes "-arithmetic" option non-attractive.

-- 
With best regards,
Dmitry

Bug#845267: Bug#741112 closed by Debian FTP Masters (Bug#845053: Removed package(s) from unstable)

[Francesco Poli]

Control: retitle -1 libopenfoam: libscotchDecomp.so.0.1.0 is GPL-licensed but 
links with GPL-incompatible library


On Mon, 21 Nov 2016 23:12:14 +0100 Francesco Poli wrote:

> Control: clone -1 -2
> Control: reassign -2 libopenfoam 4.0+dfsg1-5
> Control: reopen -2
[...]

I forgot to retitle the bug report...


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


pgpFF3rT8kDxp.pgp
Description: PGP signature

Bug#845254: unblock: win32-loader/0.8.0

[Cyril Brulebois]

Emilio Pozuelo Monfort  (2016-11-21):
> On 21/11/16 23:09, Cyril Brulebois wrote:
> > As noted in my previous mail, that should be an unblock-udeb instead. ;)
> 
> I guess you have no objections from a d-i RM perspective?

Right, sorry; the mail I mentioned was for debian-boot@… there, I was
stating I'm fine with trusting Didier on this:
  https://lists.debian.org/debian-boot/2016/11/msg00256.html

so feel free to let this package get into testing when it's copied over
by ftpmasters.


KiBi.


signature.asc
Description: Digital signature

Bug#845254: unblock: win32-loader/0.8.0

[Emilio Pozuelo Monfort]

On 21/11/16 23:09, Cyril Brulebois wrote:
> Didier 'OdyX' Raboud  (2016-11-21):
>> Please unblock package win32-loader 0.8.0. win32-loader is special in that it
>> is always 'block'ed, because it needs manual ftpmaster intervention on
>> migration:
>>
>>> # doesn't actually produce udebs, but blocked RoM (not d-i RM): it gets
>>> # handled by the ftp team so make sure the package migrates at the same time
>>> # it gets copied into debian/tools/$suite.
>>> block-udeb win32-loader
>>
>> 0.8.0 is long overdue in stretch, please let it migrate. ftpmaster: please
>> copy debian/tools/win32-loader/unstable into …/testing 
>>
>> unblock win32-loader/0.8.0
> 
> As noted in my previous mail, that should be an unblock-udeb instead. ;)

I guess you have no objections from a d-i RM perspective?

Cheers,
Emilio

Bug#725768: And now with the patch, sorry

[Martin Quinson]

Index: j/tkcvs-8.2.3/debian/control
===
--- j.orig/tkcvs-8.2.3/debian/control
+++ j/tkcvs-8.2.3/debian/control
@@ -8,7 +8,7 @@ Build-Depends: debhelper (>= 7.0.0)
 
 Package: tkcvs
 Architecture: all
-Depends: cvs | subversion, tk8.4 | tk8.5, ttf-dejavu, ${misc:Depends}
+Depends: cvs | subversion, tk (>=8.4), ttf-dejavu, ${misc:Depends}
 Replaces: tkdiff
 Provides: tkdiff
 Recommends: xterm | x-terminal-emulator, dirdiff
Index: j/tkcvs-8.2.3/debian/control
===
--- j.orig/tkcvs-8.2.3/debian/control
+++ j/tkcvs-8.2.3/debian/control
@@ -8,7 +8,7 @@ Build-Depends: debhelper (>= 7.0.0)
 
 Package: tkcvs
 Architecture: all
-Depends: cvs | subversion, tk8.4 | tk8.5, ttf-dejavu, ${misc:Depends}
+Depends: cvs | subversion, tk (>=8.4), ttf-dejavu, ${misc:Depends}
 Replaces: tkdiff
 Provides: tkdiff
 Recommends: xterm | x-terminal-emulator, dirdiff


signature.asc
Description: PGP signature

Bug#842254: [pkg-golang-devel] Bug#842254: Bug#842254: Bug#842254: Bug#842254: Bug#842254: Bug#842254: please allow to use gccgo on architectures providing golang

[Peter Colberg]

On Mon, Nov 21, 2016 at 10:45:19PM +1300, Michael Hudson-Doyle wrote:
> Most of those 632 should probably not depend on either really, and some are
> of course ok. The number dropped by 20 or so when I updated my sid chdist
> so that's good :)

The ~20 is the result of me porting acmetool to all release archs :-).

https://buildd.debian.org/status/logs.php?pkg=acmetool&ver=0.0.58-4

Thanks everyone for your work on integrating gccgo in Debian!

Peter

Bug#845268: slurmd restart points to a non-existent readme: /usr/share/doc/slurmd/README.Debian

[Harka Gyozo]

Package: slurmd
Version: 14.03.9-5
Severity: minor

Dear Maintainer,

After the slurmd install, initiating
/etc/init.d/slurmd restart
it displays:
"Please follow the instructions in /usr/share/doc/slurmd/README.Debian"
But no such file or directory

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

Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages slurmd depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18+deb8u6
ii  libhwloc51.10.0-3
ii  libpam0g 1.1.8-3.1+deb8u1+b1
ii  lsb-base 4.1+Debian13+nmu1
ii  munge0.5.11-1.1+b1
ii  openssl  1.0.1t-1+deb8u5
ii  openssl-blacklist0.5-3
ii  slurm-wlm-basic-plugins  14.03.9-5

slurmd recommends no packages.

slurmd suggests no packages.

-- no debconf information

Bug#818107: The future of DocOnce

[Francesco Poli]

On Mon, 7 Nov 2016 21:57:11 +0100 Francesco Poli wrote:

[...]
> Now I hope the Debian Python Applications Packaging Team will consider
> packaging it...

Dear Debian Python Applications Packaging Team,
will you consider packaging the new version, please?

Please let me know, thanks for your time.
Bye.

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


pgpweQPM4i9h1.pgp
Description: PGP signature

Bug#741112: closed by Debian FTP Masters (Bug#845053: Removed package(s) from unstable)

[Francesco Poli]

Control: clone -1 -2
Control: reassign -2 libopenfoam 4.0+dfsg1-5
Control: reopen -2


On Mon, 21 Nov 2016 06:18:09 + Debian Bug Tracking System wrote:

> Dear submitter,
> 
> as the package freefoam has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.
[...]

Package freefoam has been removed, but an identical issue is present in
package openfoam.
I am therefore cloning, reassigning, and reopening this bug report...

Bye.

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


pgpLTzYf8OiQT.pgp
Description: PGP signature

Bug#845254: unblock: win32-loader/0.8.0

[Cyril Brulebois]

Didier 'OdyX' Raboud  (2016-11-21):
> Please unblock package win32-loader 0.8.0. win32-loader is special in that it
> is always 'block'ed, because it needs manual ftpmaster intervention on
> migration:
> 
> > # doesn't actually produce udebs, but blocked RoM (not d-i RM): it gets
> > # handled by the ftp team so make sure the package migrates at the same time
> > # it gets copied into debian/tools/$suite.
> > block-udeb win32-loader
> 
> 0.8.0 is long overdue in stretch, please let it migrate. ftpmaster: please
> copy debian/tools/win32-loader/unstable into …/testing 
> 
> unblock win32-loader/0.8.0

As noted in my previous mail, that should be an unblock-udeb instead. ;)


KiBi.


signature.asc
Description: Digital signature

Bug#845265: how-can-i-help: using head corrupts the output of how-can-i-help

[shirish शिरीष]

Package: how-can-i-help
Version: 14
Severity: normal

Dear Maintainer,
I tried using head on how-can-i-help and got the following output -

[$] how-can-i-help --old | head
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

Packages where help is needed, including orphaned ones (from WNPP):
 - abiword - https://bugs.debian.org/740678 - O (Orphaned)
 - accountsservice - https://bugs.debian.org/842851 - O (Orphaned)
 - acheck - https://bugs.debian.org/710151 - O (Orphaned)
 - acheck-rules - https://bugs.debian.org/710152 - O (Orphaned)
 - alien - https://bugs.debian.org/791522 - O (Orphaned)
 - apt-rdepends - https://bugs.debian.org/487125 - O (Orphaned)
 - apt-xapian-index - https://bugs.debian.org/813201 - O (Orphaned)
/usr/bin/how-can-i-help:280:in `write': Broken pipe @ io_write -
 (Errno::EPIPE)
from /usr/bin/how-can-i-help:280:in `puts'
from /usr/bin/how-can-i-help:280:in `puts'
from /usr/bin/how-can-i-help:280:in `block in '
from /usr/bin/how-can-i-help:279:in `each'
from /usr/bin/how-can-i-help:279:in `'

Can the above be fixed please ?

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

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

Versions of packages how-can-i-help depends on:
ii  ruby 1:2.3.0+4
ii  ruby-debian  0.3.9+b6
ii  ruby-json2.0.1+dfsg-2

how-can-i-help recommends no packages.

how-can-i-help suggests no packages.

-- no debconf information


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

Bug#812280: Fix/Workaround for the newmat FTBFS

[Robert Davies]

I have made a fix to the code but haven't tested it yet on all compilers.
There is one other problem that gives a lot of warnings with
some compilers that I am still trying to understand.

One wants to switch to C++14 if one possibly can.

What do I need to do when I am satisfied with the updated version?

Robert



At 10:07 AM 22/11/2016, Adrian Bunk wrote:


Control: tags -1 patch

What broke the build is that gcc 6 changed the default C++ standard
from C++98 to C++14.

Not all valid C++98 code is also valid C++11 and C++14 code.

Note that this just changed the default, when told to process C++98 code
gcc 6 does not differ in any significant way from gcc 5.

Making the code compatible with C++14 would be the best possible
solution, but as a workaround it is possible to fix the build with
this change to tell gcc that this is C++98 code.

CXXFLAGS set in debian/rules were not used at all, this is also fixed.

--- debian/rules.old2016-11-21 21:00:13.0 +
+++ debian/rules2016-11-21 21:02:13.0 +
@@ -15,6 +15,8 @@
CXXFLAGS += -O2
 endif

+CXXFLAGS += -std=gnu++98
+
 # shared library versions,
 version=`ls src/.libs/lib*.so.* | \
 awk '{if (match($$0,/[0-9]+\.[0-9]+\.[0-9]+$$/)) print substr($$0,RSTART)}'`
@@ -33,7 +35,7 @@

 configure-stamp: config-stamp
dh_testdir
-   CFLAGS="$(CFLAGS) -Wl,-z,defs" \
+   CXXFLAGS="$(CXXFLAGS)" CFLAGS="$(CFLAGS) -Wl,-z,defs" \
./configure --host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr \
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info


cu
Adrian

--

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#845264: RFS: ublock-origin/1.9.16+dfsg-1~bpo8+1

[Sean Whitton]

Package: sponsorship-requests
Severity: normal
Control: block 844003 by -1

Dear mentors,

I am looking for a sponsor for a backport of ublock-origin.

* Package name: ublock-origin
  Version : 1.9.16+dfsg-1~bpo8+1
  Upstream Author : Raymond Hill
* URL : https://github.com/gorhill/uBlock
* License : GPL-3+
  Section : web

Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/u/ublock-origin/ublock-origin_1.9.16+dfsg-1~bpo8+1.dsc

Or from git:

gbp clone --pristine-tar 
https://anonscm.debian.org/git/pkg-mozext/ublock-origin.git
cd ublock-origin
git verify-tag debian/1.9.16+dfsg-1_bpo8+1 # please obtain my key from 
keyring.debian.org
git checkout debian/1.9.16+dfsg-1_bpo8+1
gbp buildpackage

Changes since the last upload:

  * Rebuild for jessie-backports (Closes: #844003).
  * Add README.Debian (see discussion in #844003).
  * Update 'debian-branch' in d/gbp.conf for backporting.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#845263: jessie-pu: package w3m/0.5.3-19+deb8u1

[Tatsuya Kinoshita]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi, the release team,

I'd like to update package w3m in jessie to fix multiple security
flaws, CVE ID assigned issues and similar issues, managed as no DSA.

cf. https://security-tracker.debian.org/tracker/source-package/w3m
http://www.openwall.com/lists/oss-security/2016/11/18/3

See this changelog and the attached debdiff.

w3m (0.5.3-19+deb8u1) jessie; urgency=medium

  * New patch 901_ucsmap.patch to fix array index (closes: #820162)
  * New patch 902_johab1.patch to fix array index (closes: #820373)
  * New patch 903_input-type.patch to fix null deref [CVE-2016-9430]
  * New patch 904_form-update.patch to fix overflow
[CVE-2016-9423] [CVE-2016-9431]
  * New patch 905_textarea.patch to fix heap write [CVE-2016-9424]
  * New patch 906_form-update.patch to fix bcopy size [CVE-2016-9432]
  * New patch 907_iso2022.patch to fix array index [CVE-2016-9433]
  * New patch 908_forms.patch to fix null deref [CVE-2016-9434]
  * New patch 909_button-type.patch to fix rodata write [CVE-2016-9437]
  * New patch 910_input-alt.patch to fix null deref [CVE-2016-9438]
  * New patch 911_rowcolspan.patch to fix stack smashing [CVE-2016-9422]
  * New patch 912_i-dd.patch to fix uninit values
[CVE-2016-9435] [CVE-2016-9436]
  * New patch 913_tabwidth.patch to fix heap corruption [CVE-2016-9426]
  * New patch 914_curline.patch to fix near-null deref [CVE-2016-9440]
  * New patch 915_table-alt.patch to fix near-null deref [CVE-2016-9441]
  * New patch 916_anchor.patch to fix heap write
[CVE-2016-9425] [CVE-2016-9428]
  * New patch 917_strgrow.patch to fix potential heap buffer corruption
[CVE-2016-9442]
  * New patch 918_form-value.patch to fix null deref [CVE-2016-9443]
  * New patch 919_form-update.patch to fix buffer overflow [CVE-2016-9429]
  * New patch 920_table.patch to fix stack overflow [CVE-2016-9439]
(closes: #844726)
  * New patch 921_cotable.patch to fix null deref
  * New patch 922_lineproc.patch to fix null deref
  * New patch 923_tagproc.patch to fix negative size allocation
  * New patch 924_curline.patch to fix near-null deref
  * New patch 925_lineproc.patch to fix stack overflow
  * New patch 926_indent-level.patch to fix stack overflow
  * New patch 927_symbol.patch to fix array index
  * New patch 928_form-id.patch to fix null deref
  * New patch 929_anchor.patch to fix null deref
  * New patch 930_tbl-mode.patch to fix null deref
  * New patch 931_parse-url.patch to fix global-buffer-overflow
  * New patch 932_ucsmap.patch to fix global-buffer-overflow

 -- Tatsuya Kinoshita   Tue, 22 Nov 2016 00:34:52 +0900

Please let me know if I can upload it.

Thanks,
--
Tatsuya Kinoshita


w3m.debdiff
Description: Binary data


pgpUJaf6PgbRa.pgp
Description: PGP signature

Bug#845177: patch

[Adam Borowski]

Control: tags -1 +patch

Here's the obvious patch.

It has an extra bonus of working even when the TERM variable is unset or set
to something that terminfo doesn't recognize.

Please apply before the freeze, if you do we'll be able to flip the default
for CONFIG_VGACON_SOFT_SCROLLBACK_PERSISTENT two years sooner.


Meow!
-- 
A true bird-watcher waves his tail while doing so.
diff -Nru bash-4.4/debian/clear_console.c bash-4.4/debian/clear_console.c
--- bash-4.4/debian/clear_console.c	2013-10-23 14:41:22.0 +0200
+++ bash-4.4/debian/clear_console.c	2016-11-21 21:31:17.0 +0100
@@ -172,6 +172,12 @@
   struct vt_stat vtstat;
 #endif
 
+  /* Linux console secure erase (since 2.6.39), this is sufficient there;
+ other terminals silently ignore this code.  If they don't and write junk
+ instead, well, we're clearing the screen anyway.
+   */ 
+  write(1, "\e[3J", 4);
+
   /* clear screen */
   setupterm((char *) 0, 1, (int *) 0);
   if (tputs(clear_screen, lines > 0 ? lines : 1, putch) == ERR)

Bug#762454: Pending fixes for bugs in the libarchive-zip-perl package

[pkg-perl-maintainers]

tag 762454 + pending
thanks

Some bugs in the libarchive-zip-perl package are closed in revision
df46dcdc9e84f433f89aae5bf7a57c9efa8856b0 in branch 'master' by
Florian Schlichting

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libarchive-zip-perl.git/commit/?id=df46dcd

Commit message:

Make crc32 error message unambiguous (closes: #762454)

Bug#845261: ITP: golang-github-sasha-s-go-deadlock -- Online deadlock detection in go (golang)

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-sasha-s-go-deadlock
  Version : 0.0~git20160726.0.09aefc0-1
  Upstream Author : sasha-s
* URL : https://github.com/sasha-s/go-deadlock
* License : Apache-2.0
  Programming Lang: Go
  Description : Online deadlock detection in go (golang)

This is needed for the last version of Syncthing

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#845183: mono-gac: missing nunit assemblies prevent installation

[Stephen Kitt]

Hi Jo,

On Mon, 21 Nov 2016 09:23:28 +, Jo Shields  wrote:
> On 21/11/16 08:25, Stephen Kitt wrote:
> > Installing libnunit-core2.6.3-cil and libnunit-framework2.6.3-cil
> > fixes the issue.  
> 
> I think I know what the bug might be here.
> /var/lib/dpkg/info/libnunit-core2.6.3-cil.postrm should be part of
> /var/lib/dpkg/info/libnunit-core2.6.3-cil.prerm - as-is, the postrm
> *could* get called in an order where /usr/share/cli-common/policy-remove
> fails (e.g. when uninstalling all of mono), so the `rm
> /usr/share/cli-common/packages.d/$POLICY.installcligac` never gets
> called due to the `set -e`
> 
> This bug could well be 10 years old. Huh.

Ah yes, that does seem like the culprit — I have removed all of mono in the
past, then reinstalled it. Removing the nunit packages again does clear
everything away properly and mono-gac can be reconfigured without any
issues.

Regards,

Stephen


pgpRPwql5nmuq.pgp
Description: OpenPGP digital signature

Bug#814881: nslcd restart failures

[Ferenc Wágner]

Salvatore Bonaccorso  writes:

> On Tue, May 17, 2016 at 04:45:35PM +0200, Ferenc W??gner wrote:
> 
>> This bug really hurts our jessie systems.  Can we expect a stable
>> update with the fix?
>
> Attached is a proposed debdiff, as with the patch used for the
> unstable uplaod.

I can confirm that it works as intended.  To make the issue easily
reproducible, I inserted a sleep(3) call at the start of the exit
handler.  With the original init script service nslcd stop returns
immediately (and removes the pid file) while the daemon is still
running.  If a new daemon is started before the previous one terminates,
the exit handler removes the pid file and the socket of the new daemon.
As I understand it, systemctl has no separate "restart" action, but
translates that into stop+start, thus service nslcd restart is racy
under systemd but works fine under SysV init.  With the proposed patch,
however, the stop action of the init script does not return immediately
but waits for the daemon to terminate, thus fixing the restart action
under systemd.  Please make this update happen.
-- 
Thanks,
Feri

Bug#845171: [pkg-wine-party] Bug#845171: wine-development: FTBFS: ld aborts or segfaults

[Michael Gilbert]

On Sun, Nov 20, 2016 at 9:16 PM, Jens Reyer wrote:
> wine-development 1.9.22-1 (in stretch) built successfully on all
> architectures when it was uploaded to unstable, but fails to
> build in a stretch environment on i386 now (amd64 is still fine).
> Exactly the same for 1.9.23-1 on i386 in a sid environment:

Hi Jens,

1.9.23-1 built for me ok in a sid i386 chroot.  Can you clarify the
setup where it fails?  Did you mean kfreebsd-i386?

A recent change to binutils adds -Wl,--enable-new-dtags by default.
That may be the cause of the problem on arm.

The i386 and arm failures are probably different issues.

Best wishes,
Mike

Bug#812280: Fix/Workaround for the newmat FTBFS

[Adrian Bunk]

Control: tags -1 patch

What broke the build is that gcc 6 changed the default C++ standard
from C++98 to C++14.

Not all valid C++98 code is also valid C++11 and C++14 code.

Note that this just changed the default, when told to process C++98 code 
gcc 6 does not differ in any significant way from gcc 5.

Making the code compatible with C++14 would be the best possible 
solution, but as a workaround it is possible to fix the build with
this change to tell gcc that this is C++98 code.

CXXFLAGS set in debian/rules were not used at all, this is also fixed.

--- debian/rules.old2016-11-21 21:00:13.0 +
+++ debian/rules2016-11-21 21:02:13.0 +
@@ -15,6 +15,8 @@
CXXFLAGS += -O2
 endif
 
+CXXFLAGS += -std=gnu++98
+
 # shared library versions,
 version=`ls src/.libs/lib*.so.* | \
 awk '{if (match($$0,/[0-9]+\.[0-9]+\.[0-9]+$$/)) print substr($$0,RSTART)}'`
@@ -33,7 +35,7 @@
 
 configure-stamp: config-stamp
dh_testdir
-   CFLAGS="$(CFLAGS) -Wl,-z,defs" \
+   CXXFLAGS="$(CXXFLAGS)" CFLAGS="$(CFLAGS) -Wl,-z,defs" \
 ./configure --host=$(DEB_HOST_GNU_TYPE) \
 --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr \
 --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#830509: current status?

[Raphael Hertzog]

Hello everybody,

On Thu, 10 Nov 2016, Kamaraju Kusumanchi wrote:
> Currently, zim recommeds python-gtkspell. But since that is longer
> available, zim should probably recommend python-gtkspellcheck.
> However, it seems[1] zim crashes with the 3.0-1.1 version of
> python-gtkspellcheck. So, it would be nice if we can upgrade this to
> the latest version.
> [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834405

zim maintainer here. I needed a new version of the module for zim
so I adopted the package under the python-modules umbrella and cleaned it
up.

Carlos and Ben, if you still want to help maintain this package, then you
are welcome to join the python-modules team and manage the package there:
https://anonscm.debian.org/cgit/python-modules/packages/pygtkspellcheck.git

https://wiki.debian.org/Teams/PythonModulesTeam

For now, you are not listed as Uploaders but I have no problem
if you want to add yourself, on the contrary. I have no special
interest in this package except for the fact that zim uses it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#845260: kernel-common: hard lockup with Call Trace after upgrading from 4.2 to 4.8 kernel

[Galen Thurber]

Package: kernel-common
Version: kernel
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation?
upgraded Sparky Linux 4, kernel 4.2 to 4.8 via safe upgrade method
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
was able to only boot to single recovery mode.
Managed to boot once with 4.2 kernel to report this
   * What was the outcome of this action?
boots to 4.8 result in hard lockup after Call Trace
   * What outcome did you expect instead?
normal boot, then xserver



-- System Information:
Distributor ID: Sparky
Description:SparkyLinux
Release:4
Codename:   Tyche
Architecture: i686

Kernel: Linux 4.2.0-1-586
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#845239: Not for jessie and old stable

[Bastien ROUCARIES]

control: notfound -1 8:6.7.7.10-5+deb7u7
control: notfound -1 8:6.8.9.9-5+deb8u5

bug is not present before sid

Bug#821537: Fix from Ubuntu for netmrg

[Adrian Bunk]

Control: tags -1 patch

The fix I found in Ubuntu for these bugs is attached.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -pruN 0.20-7/debian/control 0.20-7ubuntu2/debian/control
--- 0.20-7/debian/control	2016-04-07 08:18:26.0 +
+++ 0.20-7ubuntu2/debian/control	2016-04-07 08:18:26.0 +
@@ -1,8 +1,8 @@
 Maintainer: Uwe Steinmann 
-Build-Depends: rrdtool (>= 1.3.1-4), debhelper (>= 5), debconf, libxml2-dev, libmysqlclient15-dev, libsnmp-dev, xsltproc, docbook-xsl, docbook-xml
+Build-Depends: rrdtool (>= 1.3.1-4), debhelper (>= 5), debconf, libxml2-dev, libmysqlclient-dev, libsnmp-dev, xsltproc, docbook-xsl, docbook-xml
 Standards-Version: 3.7.2
 
 Package: netmrg
 Architecture: any
-Depends: adduser, rrdtool, apache2 | httpd, php5 | php4 | php5-cgi | php4-cgi, php5-cli | php4-cli, php5-mysql | php4-mysql, mysql-client, debconf, wwwconfig-common, ${shlibs:Depends}, ${misc:Depends}
+Depends: adduser, rrdtool, apache2 | httpd, php | php-cgi, php-cli, php-mysql, mysql-client, debconf, wwwconfig-common, ${shlibs:Depends}, ${misc:Depends}
 Suggests: mysql-server

Bug#845253: icedove: Contrast ratio reduced in message list and folder panes.

[Tim Small]

Package: icedove
Version: 1:45.5.0-1
Followup-For: Bug #845253

Workaround for /chrome/userChrome.css:

/* Make folder pane and message pane text dark grey or black */
treechildren {
color: #1f1c1b;
/* color: black; */
}