Bug#800800: [Pkg-virtualbox-devel] Bug#800800: vagrant: Running vagrant up to start a VM fails with error

[L. Guruprasad]

On Monday 05 October 2015 08:45 PM, Antonio Terceiro wrote:
> it works just fine for me, and I didn't have to install anything besides 
> virtualbox
> 
> $ vagrant init debian/jessie64
> A `Vagrantfile` has been placed in this directory. You are now
> ready to `vagrant up` your first virtual environment! Please read
> the comments in the Vagrantfile as well as documentation on
> `vagrantup.com` for more information on using Vagrant.
> $ vagrant up --provider virtualbox
> Bringing machine 'default' up with 'virtualbox' provider...
> ==> default: Box 'debian/jessie64' could not be found. Attempting to find and 
> install...
> [...provisioning log...]

It looks like the issue is with the vagrant box I was using. When using
debian/jessie64 box, it works fine for me. So I guess this issue can be
closed now. In case I find something which indicates that something
could be wrong with vagrant, I will reply to this bug again.

Thanks & Regards,
Guruprasad

Bug#674486: gparted: Gparted doesn't open with sudo

[Peter Easthope]

On Mon, October 5, 2015 9:28 am, Phil Susi wrote:
> It appears that you do not have your DISPLAY environment variable set,
> so no X11 apps will work.

peter@joule:~$ echo $DISPLAY
:0

LXDE is used routinely.  No other problems observed with applications.
xeyes, for example, works.

   ... P.

-- 
Telephone 1 360 639 0202 or +13606390202.
Bcc: peter at easthope.ca  http://easthope.ca/Shop.html

Bug#797888: RFS: panda3d/1.9.0-1 [ITP] -- Panda3D free 3D engine SDK

[Jörn Schönyan]

Hi,

again sorry for the delay.


- please switch the rules file to debhelper calls :)


What exactly?


-"install -m 644 debian/shlibs debian/panda3d1.9.0/DEBIAN/shlibs"


Fixed.

all the DEB_HOST_MULTIARCH (I guess, didn't try) might be fixed by patching the 
makepanda/makepanda.py file (probably around line 1596) and maybe somewhere else


I would like to avoid that, mainly because the work would be obsolete soon, 
as upstream wants to switch to CMake in the (more or less) near future.



- please limit to 80 chars the contrl file (I mean the line length)


Done.


- section games maybe?


Sure.


- panda3d should depend on the library with a "(= ${binary:Version})"
- rename panda3d1.9.0 to libpanda3d1.9.0?


Did that, too.


panda3d1.9.0.install:
built/lib/lib*.so usr/lib/${DEB_HOST_MULTIARCH}/panda3d/
this should be in the -dev package


You realized that these files aren't symlinks but libraries? So really 
don't think this would be correct. One example:


-rw-r--r-- 1 root root   772576 Aug 10 11:01 libpandagl.so

Best regards, Jörn

Bug#801054: piuparts: piupart should order the deb files given to 'dpkg -i' when passed a changes file

[Guilhem Moulin]

Package: piuparts
Version: 0.66
Severity: wishlist

Dear Maintainer,

`piuparts --schroot=unstable-amd64-sbuild […] dropbear_2015.68-1_amd64.changes`
fails because the .deb files are not properly ordered when given to `dpkg -i`.
Indeed, piuparts runs

dpkg -i tmp/dropbear-bin_2015.68-1_amd64.deb \
tmp/dropbear-initramfs_2015.68-1_amd64.deb \
tmp/dropbear-run_2015.68-1_amd64.deb \
tmp/dropbear_2015.68-1_all.deb

which fails during the upgrade test.  ('dropbear' used to be a regular
package but is now a dummy transitional package depending on
dropbear-{bin,initramfs}; each in turn depending on dropbear-bin and
breaking+replacing the former 'dropbear' [0].)

However replacing the changes file by pre-ordered deb files makes
piuparts happy:

piuparts --schroot=unstable-amd64-sbuild […] \
dropbear_2015.68-1_all.deb \
dropbear-bin_2015.68-1_amd64.deb \
dropbear-run_2015.68-1_amd64.deb \
dropbear-initramfs_2015.68-1_amd64.deb

Indeed `dpkg -i` seems to install its arguments sequentially.  Hence
piuparts should probably build the dependency graph to figure out how to
order the binary packages passed to `dpkg -i`.  Or alternatively, let
APT do that by replacing `dpkg -i` with `apt install` and a file://
local source.

This is especially interesting for tools like sbuild(1) which are
interacting with piuparts by merely passing changes file.

Thanks!
-- 
Guilhem.

[0] 
https://anonscm.debian.org/cgit/collab-maint/dropbear.git/tree/debian/control


signature.asc
Description: PGP signature

Bug#801055: Update with compiler information

[Jeffrey Walton]

My bad... I probably should have sent this with the original report.

# g++ -Wall -c test.cxx
test.cxx:13:9: warning: #pragma GCC target is not supported for this
machine [-Wpragmas]
 #pragma GCC pop_options
 ^

**

# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian
5.2.1-21' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-5 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libitm --disable-libquadmath --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf
--with-arch-directory=arm
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.2.1 20151003 (Debian 5.2.1-21)

**

# apt-cache show gcc
Package: gcc
Source: gcc-defaults (1.145)
Version: 4:5.2.1-4
Installed-Size: 41
Maintainer: Debian GCC Maintainers 
Architecture: armhf
Provides: c-compiler
Depends: cpp (>= 4:5.2.1-4), gcc-5 (>= 5.2.1-13~)
Recommends: libc6-dev | libc-dev
Suggests: gcc-multilib, make, manpages-dev, autoconf, automake,
libtool, flex, bison, gdb, gcc-doc
Conflicts: gcc-doc (<< 1:2.95.3)
Description-en: GNU C compiler
 This is the GNU C compiler, a fairly portable optimizing compiler for C.
 .
 This is a dependency package providing the default GNU C compiler.
Description-md5: c7efd71c7c651a9ac8b2adf36b137790
Build-Essential: yes
Tag: devel::compiler, devel::lang:c, interface::commandline,
 role::metapackage, role::program, suite::gnu,
 works-with::software:source
Section: devel
Priority: optional
Filename: pool/main/g/gcc-defaults/gcc_5.2.1-4_armhf.deb
Size: 5224
MD5sum: 39db011e121fc859d45bc134257fc977
SHA1: d2d77ceca803db1d23f38197101e5e0aa40c4775
SHA256: 0d1af3a0cb11be39fb67c39f4bcb24dce11d6b2fb251ace99ca487cd66d32510

Bug#800834: ardour: Freesound search stops work

[Debian/GNU]

Control: tags -1 confirmed
Control: tags -1 upstream
thanks


On 10/04/2015 09:37 AM, Massimo Barbieri wrote:
> Package: ardour
> Version: 1:4.2~dfsg-5
> Severity: minor
> 
> Dear Maintainer,
> in the add media window the freesound search by tag doesn't show any results.
> Thanks for your work!

this is a known upstream issue (see [1], [2]): ardour still only
supports the FreeSound v1 query API, which seems t ohave finally retired.

gfmads
IOhannes


[1] http://tracker.ardour.org/view.php?id=6197
[2] http://tracker.ardour.org/view.php?id=6493




signature.asc
Description: OpenPGP digital signature

Bug#801060: scilab: FTBFS on ppc64el

[Emilio Pozuelo Monfort]

Source: scilab
Version: 5.5.2-1.1
Severity: serious
Control: block 798256 with -1

Your package failed to build on ppc64el

Excerpt from the build log:

checking if jni.h can be included... yes
Looking for JNI libs with ppc64 as machine hardware name
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/ppc64/libjava.so
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/amd64/libjava.so
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/i386/client/libjvm.so
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/bin/classic/libjvm.so
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/lib/jvm.lib
Looking for /usr/lib/jvm/java-7-openjdk-ppc64el/jre/lib/mipsel/libjava.so
configure: error: Could not detect the location of the Java
shared library. You will need to update java.m4
to add support for this JVM configuration.
/usr/share/cdbs/1/class/autotools.mk:42: recipe for target
'debian/stamp-autotools' failed

Full build log at
https://buildd.debian.org/status/fetch.php?pkg=scilab=ppc64el=5.5.2-1.1=1444066243

Cheers,
Emilio

Bug#765886: [buildd-tools-devel] Bug#765886: Bug#765886: Bug#765886: sbuild: [PATCH] Replaced all unicode-printed chars with plain ASCII

[Johannes Schauer]

Hi,

Quoting Lennart Sorensen (2015-10-05 18:33:42)
> The unicode boxes make the build log MUCH more readable in my opinion,

unfortunately this is not a very hard argument as "readability" is quite a
subjective measure. What do you think would let us get a more quantifiable
argument in this direction?

> although having fallback to ascii if unicode isn't supported on a system
> would be nice (or having an option to use ascii, given who knows if the build
> is even running under any kind of locale really).

Auto-detecting whether the system supports unicode or not and then using the
according variant would not help here. sbuild is probably only run on Debian or
derivatives which handle unicode characters just fine for a long time, so the
result would probably be that the characters would always be used in the build
logs. But this would defeat the main purpose to *not* use unicode characters.
See the next paragraph.

> But without some way to control it, your patch is "wrong" because the unicode
> boxes are a useful feature to a lot of users.

Then please explain the use case to me.

I don't have a degree in art but this:

┌──┐
│ Update chroot│
└──┘

looks close enough to my eyes to this:

+--+
| Update chroot|
+--+

That I don't see the argument. Are we really talking about a solid line looking
better than a dashed line here?

On the other hand, there are actual arguments against it:

 - using unicode characters is not strictly required here (as it would be for a
   program handling international script)
 - the sbuild log might be used outside of Debian in a world where not yet
   everybody can process non-ASCII characters (this is the reason why we don't
   want to autodetect whether the system running sbuild can do unicode)
 - if one wants to search for the headers (with command line tools or in
   editors) then (at least with my keyboard) it is easier to search for
   "---" than to type "──"
 - it is not the place of a program that just builds packages in a chroot to
   enforce unicode support on all the tools and users that handle its logs

> Just because you don't like unicode is no reason to just throw something
> away.

Agreed, if it was just because I don't like unicode then that would be no
reason to throw it away. But you might've missed the actual arguments *against*
using unicode characters in bug #665847. For your convenience I have listed
them again above.

cheers, josch


signature.asc
Description: signature

Bug#765886: [buildd-tools-devel] Bug#765886: Bug#765886: Bug#765886: sbuild: [PATCH] Replaced all unicode-printed chars with plain ASCII

[Dima Kogan]

Lennart Sorensen  writes:

> Now gcc certainly does change the output of error messages and such to
> use fancy quotes and the like when it detects unicode support in the
> environment it us running under.  Is that causing issues too then?

Yes. It doesn't break my terminal as badly as the sbuild boxes, but I
see garbage with gcc output sometimes. Doesn't happen all the time, and
I never tried to figure out what specifically makes it confused. But if
they stuck to the plain old quotes that were there for decades, it would
just work, and nobody would complain that the quotes are "ugly".

Bug#762385: ITP: mailpile -- a modern fast web-mail client with user-friendly encryption and privacy features.

[anarcat]

On Sun, Sep 21, 2014 at 06:21:58PM +, u wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ulrike Uhlig 
> 
> * Package name: wnpp
>   Version: 0.4.0
>   Upstream Author: Mailpile Team 
> * URL: https://mailpile.is
> * License: AGPL v3
>   Programming Lang: Python
> 
> Mailpile is a modern, fast web-mail client with user-friendly encryption
> and privacy features.
> Mailpile's primary user interface is web-based, but it also has a basic
> command-line interface and an API for developers. Using web technology
> for the interface allows Mailpile to function both as a local desktop
> application (accessed by visiting localhost in the browser) or a remote
> web-mail on a personal server or VPS.

What's the status on this ITP?

Relevant upstream docs i found were:

https://github.com/mailpile/Mailpile/wiki/Getting-started-on-linux
https://www.mailpile.is/download/

a.

-- 
The problem is not a lack of highly educated workers, the problem is a
lack of highly educated workers willing to work for the minimum wage or
lower in the U.S. Costs are driving outsourcing, not the quality of
American schools.   - Scott Kirwin, IT Professionals Association


signature.asc
Description: Digital signature

Bug#674486: gparted: Gparted doesn't open with sudo

[Phil Susi]

On 10/5/2015 1:54 PM, Peter Easthope wrote:
> On Mon, October 5, 2015 9:28 am, Phil Susi wrote:
>> It appears that you do not have your DISPLAY environment variable set,
>> so no X11 apps will work.
> 
> peter@joule:~$ echo $DISPLAY
> :0
> 
> LXDE is used routinely.  No other problems observed with applications.
> xeyes, for example, works.

You mean when you run it from that root shell right?

What if you try running gpartedbin directly instead of gparted?

Bug#801056: cloud.debian.org: Kernel headers are required to upgrade the guest-additions

[L. Guruprasad]

Package: cloud.debian.org
Severity: normal

Dear Maintainer,

The debian/jessie64 vagrant box published on HashiCorp Atlas doesn't have the
linux kernel headers installed. When bringing up a VM, vagrant warns if
the guest additions installed on the guest do not match with the VirtualBox
version on the host. But the VM should work fine.

There is a vagrant-vbguest plugin which automatically updates the guest
additions installed on the guest to match that of the VirtualBox version
on the host. It is widely used and even I have it installed on my system.
Since the kernel headers are not installed, the installation of the guest
additions fails and features like shared folders and etc. no longer work.

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

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

Bug#795262: nvidia-cuda-toolkit: Reboot, after package installation, do not unload the Nouveau drivers

[Andreas Beckmann]

On 2015-08-21 12:28, Luca Boccassi wrote:
> On 21 August 2015 at 11:15, François Legendre  wrote:
>> I thought IMHO that the maintainers of nvidia-cuda-toolkit should set
>> a dependency : nvidia-cuda-toolkit depends on nvidia-driver as nouveau
>> drivers are not able to run a CUDA application.

Thinking about headless systems, it's not nvidia-driver that is needed,
but just libcuda1 + the kernel module + blacklist nouveau + load the
nvidia module.

> I think it's good that there is a clear separation between the "build"
> stack and the "runtime" stack, as it is often the case.

Ack.

> The toolkit dependency chain already has a "suggests" on the
> nvidia-driver package (there might even be a "recommends" along the
> way, can't remember),

nvidia-cuda-toolkit Depends: nvidia-cuda-dev
nvidia-cuda-dev Depends: libcuda1
libcuda1 Recommends: nvidia-kernel-dkms (= $VER) | nvidia-kernel-$VER

So in a default installation which has --install-recommends enabled the
nvidia kernel module should be there.

The only bug I see is that such an installation without nvidia-driver
(or just libgl1-nvidia-glx or xserver-xorg-video-nvidia) currently does
not activate the nvidia alternative, but that is easily fixed in
glx-alternative-nvidia.


Andreas

Bug#786009: New 0.1.6-1 version of screenlets by jwilk exists in svn, but not released

[Ross Gammon]

Hi,

A new upstream release is prepared in the PAPT repository which would
fix the bug for deprecated python-support. The repository also contains
other packaging changes (e.g. switch from cdbs to dh).

I am not sure why the work stopped, but it may be better to do the
upstream release rather than NMU.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#801059: libxmu's debian/rules is not safe to execute in parallel

[Matthias Klose]

Package: src:libxmu
Version: 2:1.1.2-1
Severity: serious
Tags: sid stretch patch

seen in an Ubuntu test rebuild, however this may happen as well in a Debian 
build.

https://launchpadlibrarian.net/219669711/buildlog_ubuntu-wily-amd64.libxmu_2%3A1.1.2-1_BUILDING.txt.gz

the problem is that -j is added to MAKEFLAGS, and the binary-arch and 
binary-indep targets are executed in parallel.  The Ubuntu build now fails


dh_builddeb -s
[...]
dh_builddeb
dpkg-deb: building package 'libxmu6' in '../libxmu6_1.1.2-1_amd64.deb'.
tar: ./usr/lib/x86_64-linux-gnu/libXmu.so.6.2.0: file changed as we read it
dpkg-deb: error: subprocess tar -cf returned error exit status 1
[...]
debian/rules:101: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 1
make: *** Waiting for unfinished jobs

Every debhelper command for the architecture dependent packages are executed 
twice.

patch at
http://launchpadlibrarian.net/220316375/libxmu_2%3A1.1.2-1_2%3A1.1.2-1ubuntu1.diff.gz

(together with using dpkg-buildflags, maybe dh_autoreconf could be used as 
well).

Bug#801051: ITP: golang-github-skratchdot-open-golang -- Abstraction to open URIs using a same object type

[Fernando Ike]

Package: wnpp
Severity: wishlist
Owner: Fernando Ike 
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintainers@lists.a
lioth.debian.org

* Package name: golang-github-skratchdot-open-golang
  Version: 0.0~git20150221.0.c874831-1
  Upstream Author: Jeff Switze 
* URL: https://github.com/skratchdot/open-golang
* License: Expat
  Description: Abstraction to open URIs using a same object type

 Functions to use embedded in your programs to open a file,
 directory, or URI using the OS's default application for that object
 type. Optionally, it can specify an application to use.
 .
 This package provides a library to use abstraction open functions in
 Golang programs.


-- 
Fernando Ike
http://www.fernandoike.com

Bug#801052: midori: Midori dies with SIGILL right after loading Wikipedia page

[Andreas Neudecker]

Package: midori
Version: 0.5.11-2~bpo8+1
Severity: important

Dear Maintainer,

sadly Midori keeps crashing on random pages, all the time. One prominent
example are Wikipedia pages like http://en.wikipedia.org/wiki/Cowsay - here is
the crash report, running with the -g switch:

8<

Launching command: '/usr/bin/gdb' --batch -ex 'set print thread-events off' -ex
run -ex 'set logging on /run/user/1000/midor
i/gdb.bt' -ex 'bt' --return-child-result --args midori
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-
gnu/i686/cmov/libthread_db.so.1".
Vector smash protection is enabled.

Program received signal SIGILL, Illegal instruction.
0xae834fb5 in ?? ()
#0  0xae834fb5 in ?? ()
#1  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#2  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#3  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#4  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#5  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#6  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#7  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#8  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#9  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#10 0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#11 0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#12 0xb4c432a9 in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#13 0xb4bdf786 in JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*,
JSC::Register*) () from /usr/lib/i386-linux-gnu/libj
avascriptcoregtk-1.0.so.0
#14 0xb4bbd8bf in JSC::Interpreter::executeCall(JSC::ExecState*,
JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::J
SValue, JSC::ArgList const&) () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#15 0xb4d010f4 in JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType,
JSC::CallData const&, JSC::JSValue, JSC::ArgList c
onst&) () from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-1.0.so.0
#16 0xb5b9a3e6 in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#17 0xb5d7109d in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#18 0xb5d7155e in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#19 0xb5d82ecd in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#20 0xb5d6ae34 in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#21 0xb5d6d132 in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#22 0xb5d866a5 in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#23 0xb5f3f71f in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#24 0xb5da51e4 in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#25 0xb5da8646 in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#26 0xb5da913b in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#27 0xb5da9006 in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#28 0xb5b04e8b in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#29 0xb5b04ee2 in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#30 0xb5b2722e in ?? () from /usr/lib/i386-linux-gnu/libwebkitgtk-1.0.so.0
#31 0xb78af8d1 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#32 0xb78aecb3 in g_main_context_dispatch () from /lib/i386-linux-
gnu/libglib-2.0.so.0
#33 0xb78af0c9 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#34 0xb78af479 in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#35 0xb54631b5 in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#36 0x0804a9e6 in main (argc=1, argv=0xb204) at /build/midori-
rIwXeE/midori-0.5.11/midori/main.c:392

>8

Another very popular page/website where midori crashes directly after loading
the page is http://www.spiegel.de/ (German news magazine). The crashreport
looks more or less the same:

8<

andreas@marvin:~$ midori -g
Launching command: '/usr/bin/gdb' --batch -ex 'set print thread-events off' -ex
run -ex 'set logging on /run/user/1000/midor
i/gdb.bt' -ex 'bt' --return-child-result --args midori
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-
gnu/i686/cmov/libthread_db.so.1".
Vector smash protection is enabled.

Program received signal SIGILL, Illegal instruction.
0xae834fb5 in ?? ()
#0  0xae834fb5 in ?? ()
#1  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#2  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#3  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#4  0xb4c4684b in ?? () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#5  0xb4c4684b in ?? () from /usr/lib/i386-linux-

Bug#800776: [Debian-ha-maintainers] Bug#800776: cluster-glue: please make the build reproducible

[Reiner Herrmann]

On Mon, Oct 05, 2015 at 11:25:19AM +0200, Christoph Berg wrote:
> Re: Reiner Herrmann 2015-10-05 <20151005091641.gb22...@reiner-h.de>
> Oh sorry, I thought this bug was about a different package so I
> assumed the packaging was dh. *blush*
> 
> We are currently reworking all of the HA stack packages and
> cluster-glue hasn't been touched yet. There's chances cluster-glue
> will be dropped completely, or at least reduced to much less content.
> 
> I'll make sure to keep an eye on reproducibility!

Cool, thanks! :)



signature.asc
Description: Digital signature

Bug#801053: pbuilder: add a mean to easily include external packages during builds

[Mattia Rizzolo]

Package: pbuilder
Version: 0.200
Severity: wishlist
User: pbuil...@packages.debian.org
Usertags: pbuilder


sbuild has this shiny option, I want it too.

From sbuild(1):
--extra-package=package.deb
  Make  package.deb  available for build-dependency resolution, by
  adding it to a temporary archive created by sbuild.  This  makes
  it easier to build packages against locally-built build depenen-
  cies, without waiting for those packages to enter the  main  ar-
  chive,  or  going  through the hassle of maintaining a local ar-
  chive and making it accessible inside the  chroot.   package.deb
  is  copied  into  the chroot, so it can refer to any path on the
  host system.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#765886: [buildd-tools-devel] Bug#765886: Bug#765886: Bug#765886: sbuild: [PATCH] Replaced all unicode-printed chars with plain ASCII

[Lennart Sorensen]

On Mon, Oct 05, 2015 at 07:27:20PM +0200, Johannes Schauer wrote:
> unfortunately this is not a very hard argument as "readability" is quite a
> subjective measure. What do you think would let us get a more quantifiable
> argument in this direction?

I have no idea if anything could make that quantifiable.

> Auto-detecting whether the system supports unicode or not and then using the
> according variant would not help here. sbuild is probably only run on Debian 
> or
> derivatives which handle unicode characters just fine for a long time, so the
> result would probably be that the characters would always be used in the build
> logs. But this would defeat the main purpose to *not* use unicode characters.
> See the next paragraph.

Yes runtime detection is the wrong time to detect it.  Predicting the
future for where it will be viewed would be an impressive feat.

> Then please explain the use case to me.
> 
> I don't have a degree in art but this:
> 
> ┌──┐
> │ Update chroot   
>  │
> └──┘
> 
> looks close enough to my eyes to this:
> 
> +--+
> | Update chroot   
>  |
> +--+
> 
> That I don't see the argument. Are we really talking about a solid line 
> looking
> better than a dashed line here?

Nothing else in a build log ever looks like the sbuild boxes.  They stand
out nicely as a result.  I can't say that standing out really is ever
particularly necessary as a use case though.

> On the other hand, there are actual arguments against it:
> 
>  - using unicode characters is not strictly required here (as it would be for 
> a
>program handling international script)

It certainly isn't required.

>  - the sbuild log might be used outside of Debian in a world where not yet
>everybody can process non-ASCII characters (this is the reason why we don't
>want to autodetect whether the system running sbuild can do unicode)

Certainly detecting the environment does NOT tell you about the
environment that will be viewing the log.

Now gcc certainly does change the output of error messages and such to
use fancy quotes and the like when it detects unicode support in the
environment it us running under.  Is that causing issues too then?

>  - if one wants to search for the headers (with command line tools or in
>editors) then (at least with my keyboard) it is easier to search for
>"---" than to type "──"

True, although searching for the pretty box would almost certainly only
match the output of sbuild.

>  - it is not the place of a program that just builds packages in a chroot to
>enforce unicode support on all the tools and users that handle its logs

That is a fair argument.

> Agreed, if it was just because I don't like unicode then that would be no
> reason to throw it away. But you might've missed the actual arguments 
> *against*
> using unicode characters in bug #665847. For your convenience I have listed
> them again above.

It would seem the only way to keep pretty boxes and make things usable in
all cases would be an explicit sbuild config to choose one or the other,
which complicates the code, so that is probably not worthwhile.

I guess it is bye bye for the pretty boxes.

-- 
Len Sorensen

Bug#801055: ARMHF and "pragma GCC target is not supported for this machine" for QEMU/ARMHF

[Jeffrey Walton]

Package: qemu-user-static
Version: 1:2.1+dfsg-12+deb8u4
Severity: normal

**

This is kind of odd. I'm in a QEMU chroot environment. The compiler
accepts "pragma GCC push_options", but complains about "pragma GCC
pop_options".

My apologies in advance if this is mis-classified. I have trouble
determining where the QEMU and Debian chroot reports should go.

**

debian-armhf:/# g++ -Wall -c test.cxx
test.cxx:13:9: warning: #pragma GCC target is not supported for this
machine [-Wpragmas]
 #pragma GCC pop_options
 ^

# cat test.cxx
#include 

#pragma GCC push_options
#pragma GCC optimize("O1")

int main(int argc, char* argv[])
{
  std::cout << "Hello world" << std::endl;

  return argc;
}

#pragma GCC pop_options

**

# apt-cache show qemu-user-static
Package: qemu-user-static
Status: install ok installed
Priority: optional
Section: otherosfs
Installed-Size: 79002
Maintainer: Debian QEMU Team 
Architecture: amd64
Multi-Arch: foreign
Source: qemu
Version: 1:2.4+dfsg-3
Provides: qemu-user-binfmt
Recommends: binfmt-support
Suggests: sudo
Conflicts: qemu-user-binfmt
Description-en: QEMU user mode emulation binaries (static version)
 QEMU is a fast processor emulator: currently the package supports
 ARM, CRIS, i386, M68k (ColdFire), MicroBlaze, MIPS, PowerPC, SH4,
 SPARC and x86-64 emulation. By using dynamic translation it achieves
 reasonable speed while being easy to port on new host CPUs.
 .
 This package provides the user mode emulation binaries, built
 statically. In this mode QEMU can launch Linux processes compiled for
 one CPU on another CPU.
 .
 If binfmt-support package is installed, qemu-user-static package will
 register binary formats which the provided emulators can handle, so
 that it will be possible to run foreign binaries directly.
Description-md5: 5d8ec17cec68244efa918fa841e2964c
Built-Using: gcc-5 (= 5.2.1-17), glib2.0 (= 2.44.1-1.1), glibc (=
2.19-19), zlib (= 1:1.2.8.dfsg-2)
Homepage: http://www.qemu.org/

Package: qemu-user-static
Source: qemu
Version: 1:2.1+dfsg-12+deb8u4
Installed-Size: 79770
Maintainer: Debian QEMU Team 
Architecture: amd64
Provides: qemu-user-binfmt
Suggests: sudo
Conflicts: qemu-user-binfmt
Description-en: QEMU user mode emulation binaries (static version)
 QEMU is a fast processor emulator: currently the package supports
 ARM, CRIS, i386, M68k (ColdFire), MicroBlaze, MIPS, PowerPC, SH4,
 SPARC and x86-64 emulation. By using dynamic translation it achieves
 reasonable speed while being easy to port on new host CPUs.
 .
 This package provides the user mode emulation binaries, built
 statically. In this mode QEMU can launch Linux processes compiled for
 one CPU on another CPU.
 .
 If binfmt-support package is installed, qemu-user-static package will
 register binary formats which the provided emulators can handle, so
 that it will be possible to run foreign binaries directly.
Description-md5: 5d8ec17cec68244efa918fa841e2964c
Homepage: http://www.qemu.org/
Built-Using: gcc-4.9 (= 4.9.2-10), glib2.0 (= 2.42.1-1), glibc (=
2.19-18), zlib (= 1:1.2.8.dfsg-2)
Multi-Arch: foreign
Recommends: binfmt-support
Section: misc
Priority: optional
Filename: pool/updates/main/q/qemu/qemu-user-static_2.1+dfsg-12+deb8u4_amd64.deb
Size: 6902928
MD5sum: 4e32efb8e75d732761f3abfe05b51812
SHA1: 71ddf82d10106aad770717990e3146135762ac65
SHA256: 93734e97ce09234767ee54ec5dd63be1b5f65d4952d7b68bda7b48544972227a

Package: qemu-user-static
Source: qemu
Version: 1:2.1+dfsg-12+deb8u1
Installed-Size: 79769
Maintainer: Debian QEMU Team 
Architecture: amd64
Provides: qemu-user-binfmt
Recommends: binfmt-support
Suggests: sudo
Conflicts: qemu-user-binfmt
Description-en: QEMU user mode emulation binaries (static version)
 QEMU is a fast processor emulator: currently the package supports
 ARM, CRIS, i386, M68k (ColdFire), MicroBlaze, MIPS, PowerPC, SH4,
 SPARC and x86-64 emulation. By using dynamic translation it achieves
 reasonable speed while being easy to port on new host CPUs.
 .
 This package provides the user mode emulation binaries, built
 statically. In this mode QEMU can launch Linux processes compiled for
 one CPU on another CPU.
 .
 If binfmt-support package is installed, qemu-user-static package will
 register binary formats which the provided emulators can handle, so
 that it will be possible to run foreign binaries directly.
Description-md5: 5d8ec17cec68244efa918fa841e2964c
Multi-Arch: foreign
Homepage: http://www.qemu.org/
Built-Using: gcc-4.9 (= 4.9.2-10), glib2.0 (= 2.42.1-1), glibc (=
2.19-18), zlib (= 1:1.2.8.dfsg-2)
Section: otherosfs
Priority: optional
Filename: pool/main/q/qemu/qemu-user-static_2.1+dfsg-12+deb8u1_amd64.deb
Size: 6906010
MD5sum: 2be5a8716a455c0be237e30a0c42780d
SHA1: 21e07baa4ce2164b148151ceee94e19d58f69b46
SHA256: 4db1ed071d8cf4dd2212e51194a72741b53ce7c2dd3aa9563f65b7c910aeb0ce

**

# uname -a
Linux debian-8-x64 

Bug#801048: xdg-open broken if whitespaces in filename, also with mime filetype check

[Per Olofsson]

Hi,

Thank you for reporting.

Den 2015-10-05 kl. 18:45, skrev deb...@kesaniemi.fi:
> -local file=$1
> +local file="$1"

The irritating thing is that if I'd written

  local file
  file=$1

then it would have worked! Oh, shell...

Expect an upload soon.

-- 
Pelle

Bug#801057: qt-at-spi: New upstream version released

[Lisandro Damián Nicanor Pérez Meyer]

Source: qt-at-spi
Severity: wishlist

Hi! I'm filing this bug just because I have been involved in
releasing this version, I have no direct interest in the package.

There is a new upstream release of qt-at-spi available now at
http://download.kde.org/stable/qt-at-spi/0.4.0/src/qt-at-spi-0.4.0.tar.bz2

Happy hacking, Lisandro.

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

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

Bug#801058: ITP: nbconvert -- Jupyter notebook conversion

[Julien Puydt]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org

* Package name: nbconvert
  Version : 4.0.0
  Upstream Author : Jupyter Development Team
* URL : https://github.com/jupyter/nbconvert
* License : BSD-3-clause
  Programming Lang: Python
  Description : Jupyter notebook conversion
 Jupyter nbconvert converts notebooks to various other formats
 using Jinja templates.

Cheers,

Snark on #debian-python

Bug#801083: gthumb: unreproducible build

[Alex Vong]

Source: gthumb
Version: 3:3.4.1-1
Severity: minor

Dear Maintainer,


shows that the version of gthumb in unstable is unreproducible. The
``differences'' tag shows that the file to be installed as
/usr/share/glib-2.0/schemas/org.gnome.gthumb.enums.xml cannot be built
reproducibly.

The build log diff shows org.gnome.gthumb.enums.xml is being built
using different commands in different builds! I think this is why
org.gnome.gthumb.enums.xml cannot be built reproducibly.

Cheers,
Alex


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

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

Bug#801084: bluez-firmware: Please include firmware for Broadcom Corp. BCM20702 Bluetooth 4.0

[Fabian Greffrath]

Package: bluez-firmware
Version: 1.2-3
Severity: important

Hi there,

I have spent yesterday evening with trying to get my Bluetooth
working. After several attempts (e.g. adding my uid to the "lp" group,
because I got "DBusFailedError: No such file or directory" errors from
blueman) I found the following in my 'dmesg' output:

bluetooth hci0: Direct firmware load for brcm/BCM20702A0-0a5c-21e6.hcd
failed with error -2

Apparently, this file is missing for a proper operation of the
Bluetooth dongle on my system. However, it is not available in any
firmware package in Debian. Thus, I am asking you to add it to the
bluez-firmware package which I find most appropriate for this.

Having searched the web for this file name, I found the following site
with instructions on how to download and install it:

http://plugable.com/2014/06/23/plugable-usb-bluetooth-adapter-solving-hfphsp-profile-issues-on-linux

Once I followed the instructions on this site, I could connect all my
Bluetooth devices to my laptop.

Some additional information:

I am using a Lenovo ThinkPad T430.

# dmidecode -s bios-version; dmidecode -s bios-release-date
G1ETA6WW (2.66 )
08/19/2014

$ lsusb | grep Blue
Bus 003 Device 007: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0
[ThinkPad]

$ uname -a
Linux kff50 4.2.0-1-amd64 #1 SMP Debian 4.2.1-2 (2015-09-27) x86_64
GNU/Linux

Please tell me if you think a different package (e.g.
firmware-linux-nonfree, CC:ed) is better suited to hold this firmware,
I will then re-assign this bug there.

Thanks!

 - Fabian

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

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

-- no debconf information

Bug#798943: 64bit builds raise a lot of compiler warnings

[Matthias Klose]

Control: tags -1 + patch

>>> import dulwich._objects
Traceback (most recent call last):
  File "", line 1, in 
ImportError: 
/usr/lib/python3/dist-packages/dulwich/_objects.cpython-34m-x86_64-linux-gnu.so: 
undefined symbol: PyString_FromStringAndSize



please don't ship non-working extension modules.

patch at
http://launchpadlibrarian.net/220370260/dulwich_0.11.2-1_0.11.2-1ubuntu1.diff.gz

Bug#792096: borg packaging

[Antoine Beaupré]

On 2015-10-06 00:12:19, Gianfranco Costamagna wrote:
> Hi, Danny has finally got accepted in collab-maint
> (I forgot that a signed mail was needed for the join).
>
> In the next few days I had many other Debian activities that kept
> myself away from this bug, but I guess we will close it soon.

Happy to hear that! Keep us in the loop here. :)

A.

-- 
feature, n: a documented bug | bug, n: an undocumented feature
- Mario S F Ferreira 

Bug#801081: xserver-xorg-video-qxl: QXL video unusable due to performance

[Jason Briggs]

Minor correction:
I used the Cirrus driver on Wheezy machines. For Jessie machines I have it set 
to the VGA driver (because Cirrus has issues on Jessie guests as well). 

I had no luck trying to backport the xserver-xorg-video-qxl package from Sid 
locally on my own (green screen) and limited ability to look further.

Bug#801081: xserver-xorg-video-qxl: QXL video unusable due to performance

[Jason Briggs]

Another way to replicate:

Simply run the Jessie live CD (debian-live-8.2.0-amd64-xfce-desktop.iso) as a 
guest in Virt-Manager with QXL driver (default) and try to load Iceweasel and 
try to scroll through some websites for 10 minutes. Even with spice-vdagent 
missing, with only the qxl driver the browser is so slow and glitchy it's 
virtually unusable on my host systems.

Then kill machine and switch to VGA driver, reload VM and try Iceweasel again. 
VGA appears slower in XFCE at first but then Iceweasel runs great and speed is 
constant in general.

Again there is no spice-vdagent in the live CD so obviously the qxl driver is 
the problem.

Bug#801061: [Pkg-freeipa-devel] Bug#801061: pki-server: pki-tomcatd@.service ExecStart and ExecStop refer to non-existant path /usr/libexec/tomcat/server

[Timo Aaltonen]

On 05.10.2015 22:38, Diane Trout wrote:
> Package: pki-server
> Version: 10.2.6-2
> Severity: important
> 
> Hello again,
> 
> Thank you for the quick response for the last two bugs I filed.
> 
> I got a bit further starting up pki-server under systemd, the paths in
> the systemd .service file are wrong. I tried using 
> /usr/lib/pki/pki-tomcat/bin/startup.sh and
> /usr/lib/pki/pki-tomcat/bin/shutdown.sh 
> instead of /usr/libexec/tomcat/server which almost works.

Ok, now I see where the confusion comes from. Tomcat isn't systemd'ized
yet, so the pki-tomcat service files aren't actually used,
/etc/init.d/pki-tomcatd is. You can still use systemctl to control
pki-tomcat, show it's status etc.

I just installed a vanilla ipa server from sid, and things work fine
even after a reboot.



-- 
t

Bug#801062: (no subject)

[Tobias Platen]

Package: wnpp
Severity: wishlist
Owner: Tobias Platen 

* Package name: world
  Version : 0.2.0_4
  Upstream Author : Masanori Morise
* URL : http://ml.cs.yamanashi.ac.jp/world/english/index.html
* License : BSD
  Programming Lang: C++
  Description : high-quality speech analysis/synthesis system on 
the basis of Vocoder


WORLD was proposed to synthesize high-quality speech as natural as the 
input speech. The purpose of WORLD is reducing the computational cost of 
TANDEM-STRAIGHT without deterioration. WORLD is superior to 
TANDEM-STRAIGHT in implementing the real-time singing synthesis, whereas 
it is inferior to TANDEM-STRAIGHT in manipulating consonant flexibly. 
Since the concept of WORLD differs from that of TANDEM-STRAIGHT, you 
should select them based on your purpose. WORLD could also be used to 
replace the non-free MBROLA synthesizer.

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start

[Marvin Renich]

Package: developers-reference
Version: 3.4.16
Severity: wishlist

As discussed on debian-devel starting at [1], I would like a comment
added to Section 6.4 "Best practices for maintainer scripts" that
recommends preventing the postinst script from returning failure when a
service fails to start.

A general rule of thumb is that if the corrective action would not
otherwise require re-running dpkg, then the postinst should behave as if
the installation succeeded.

An example of a case where postinst should succeed is if the admin,
prior to an upgrade, modified a configuration file which resulted in the
service being unable to restart during the upgrade.

Another example is if the service requires another resource to be
available that might be on another machine (e.g. a database).

The rational is that the failure has nothing to do with the installation
process or the contents of the .deb.  The service might just as well
have failed on reboot even though it was correctly installed.

I will send a follow-up message that contains a condensed digest of the
thread beginning at [1].

...Marvin

[1] https://lists.debian.org/debian-devel/2015/09/msg00496.html

Bug#801066: ruby-passenger: version 4.0.53-1 in jessie breaks with ruby 2.2.x

[Mourad De Clerck]

Package: ruby-passenger
Version: 4.0.53-1
Severity: normal

Hello,

I just noticed this bug:
https://github.com/phusion/passenger/issues/1314

I hit it using ruby 2.2 (via rbenv) on an otherwise pristine jessie
installation. It'd be nice if the package could be updated to 4.0.59.
Rails 5 will require ruby 2.2 at a minimum, and I'd prefer to use Debian's
passenger package.

Thanks for your consideration,

-- Mourad DC

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

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

Versions of packages ruby-passenger depends on:
ii  libc62.19-18+deb8u1
ii  libcurl3 7.38.0-4+deb8u2
ii  libev4   1:4.15-3
ii  libgcc1  1:4.9.2-10
ii  libjsoncpp0  0.6.0~rc2-3.1
ii  libruby2.1   2.1.5-2+deb8u2
ii  libstdc++6   4.9.2-10
ii  ruby 1:2.1.5+deb8u1
ii  ruby-rack1.5.2-3+deb8u1
ii  zlib1g   1:1.2.8.dfsg-2+b1

ruby-passenger recommends no packages.

Versions of packages ruby-passenger suggests:
ii  nodejs  0.10.29~dfsg-2
ii  python  2.7.9-1
pn  rails   
pn  ruby-passenger-doc  

-- no debconf information

Bug#799449: [pkg-apparmor] Processed: severity of 799449 is serious

[Felix Geyer]

On Mon, 05 Oct 2015 21:27:58 +0200 intrigeri  wrote:
> Control: tag -1 + help
> 
> sarnold wants a stracktrace and says: "if you can get it to fail by
> hand, runniung it with gdb ought to do the trick, gdb ./tst_regex ;
> "run" "bt" iiirc.."
> 
> => anyone with access to mips* a porter box can do that and report
> back here. Help is welcome :)

Doesn't look very promising:

minkus% gdb tst_lib
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tst_lib...done.
(gdb) run
Starting program: /home/fgeyer/apparmor-2.10/parser/tst_lib
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/mips-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt full
#0  0x in ?? ()
No symbol table info available.
#1  0x005537a0 in _PROCEDURE_LINKAGE_TABLE_ ()
No symbol table info available.
Backtrace stopped: frame did not save the PC


fwiw all parser/tst_* segfault the same way.

Felix

Bug#779851: cryptmount: Me neither, but different failure mode

[R.Penney]

Thanks for reporting this bug.

I think I have diagnosed the problem - this is probably due to a change
in behaviour of /sbin/fsck, where it now relies on the PATH
environmental variable to find /sbin/fsck.ext3 etc. instead of just
searching /sbin and a few other standard places. That is a significant
difference from the version of fsck in Jessie.

I'm currently working on a fix for this, which will probably form part
of (upstream) release cryptmount-5.2. As a work-around, you could
temporarily disable fsck by using "flags=nofsck"
in /etc/cryptmount/cmtab.

Bug#801026: osgi-compendium: depends on obsolete libservlet2.5-java library

[Neil Bartlett]

This isn’t really possible. The osgi-compendium package is not just a program 
or library; it represents a specification published by a standards body, the 
OSGi Alliance. The specification supports the java servlet API 2.5 and above. 
We cannot simply update to 3.1 since that could break any consumers using 2.5 — 
also the package would not comply with the published specification.

Neil Bartlett

Bug#799449: [pkg-apparmor] Processed: severity of 799449 is serious

[intrigeri]

Control: tag -1 + help

sarnold wants a stracktrace and says: "if you can get it to fail by
hand, runniung it with gdb ought to do the trick, gdb ./tst_regex ;
"run" "bt" iiirc.."

=> anyone with access to mips* a porter box can do that and report
back here. Help is welcome :)

Bug#765886: [buildd-tools-devel] Bug#765886: Bug#765886: Bug#765886: sbuild: [PATCH] Replaced all unicode-printed chars with plain ASCII

[Lennart Sorensen]

On Mon, Oct 05, 2015 at 10:57:44AM -0700, Dima Kogan wrote:
> Yes. It doesn't break my terminal as badly as the sbuild boxes, but I
> see garbage with gcc output sometimes. Doesn't happen all the time, and
> I never tried to figure out what specifically makes it confused. But if
> they stuck to the plain old quotes that were there for decades, it would
> just work, and nobody would complain that the quotes are "ugly".

It is simply utf8 support:

lennartsorensen:/tmp# LANG=C.UTF-8 gcc -c test.c
test.c: In function ‘main’:
test.c:10:2: error: expected ‘;’ before ‘printf’
  printf("[%.2x][%.2x] -> %d\n", input[0], input[1], value);
  ^
lennartsorensen:/tmp# LANG=C gcc -c test.c
test.c: In function 'main':
test.c:10:2: error: expected ';' before 'printf'
  printf("[%.2x][%.2x] -> %d\n", input[0], input[1], value);
  ^

The quotes around the function name and other things change to fancy
begin/end quotes when unicode support is detected in the chosen LANG.

-- 
Len Sorensen

Bug#801061: pki-server: pki-tomcatd@.service ExecStart and ExecStop refer to non-existant path /usr/libexec/tomcat/server

[Diane Trout]

Package: pki-server
Version: 10.2.6-2
Severity: important

Hello again,

Thank you for the quick response for the last two bugs I filed.

I got a bit further starting up pki-server under systemd, the paths in
the systemd .service file are wrong. I tried using 
/usr/lib/pki/pki-tomcat/bin/startup.sh and
/usr/lib/pki/pki-tomcat/bin/shutdown.sh 
instead of /usr/libexec/tomcat/server which almost works.

In order to have pki-tomcat start I have to manually do:

mkdir -p /var/run/pki/tomcat 

and then I run:

chown -R pkiuser:pkiuser /var/run/pki 

Though I'm just assuming I need to do the chown based on the 
User/Group setting in the unit file.

I'm not sure those are the right startup/shutdown scripts as the
systemd unit seems like its supposed to be generic, perhaps
those shutdown/startup scripts paths should have pki-tomcat replaced 
with a macro?

Diane Trout

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

Kernel: Linux 4.2.0-1-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: systemd (via /run/systemd/system)

Versions of packages pki-server depends on:
ii  adduser   3.113+nmu3
ii  dogtag-pki-server-theme   10.2.6-2
ii  init-system-helpers   1.23
ii  ldap-utils2.4.42+dfsg-2
ii  libatk-wrapper-java   0.33.3-1
ii  libjackson-json-java  1.9.2-3
ii  libjackson2-annotations-java  2.4.2-2
ii  libjackson2-jaxrs-providers-java  2.4.2-1
ii  libjs-jquery  1.11.3+dfsg-4
ii  libjs-underscore  1.7.0~dfsg-1
ii  libnuxwdog-java   1.0.3-3
ii  libtomcatjss-java 7.1.3-3
ii  libxml-commons-external-java  1.4.01-2
ii  libxml-commons-resolver1.1-java   1.2-7
ii  pki-base  10.2.6-2
ii  pki-tools 10.2.6-2
ii  python2.7.9-1
ii  python-selinux2.3-2+b1
ii  tomcat7-user  7.0.64-1
ii  velocity  1.7-4

pki-server recommends no packages.

pki-server suggests no packages.

-- no debconf information

Bug#801064: ITP: localehelper -- A helper tool for generating locales and setting internationalization environment variables

[Jonathan Ulrich Horn]

Package: wnpp
Severity: wishlist

Package name: localehelper
Version: 0.1.3
Upstream Author: Jakub Wilk 
URL: http://jwilk.net/software/localehelper
License: Expat
Desciption: localehelper is a helper tool for generating locales and 
setting internationalization environment variables.

Bug#799126: nzbget requires specific jquery version

[Vincent van Leeuwen]

Quick message to confirm that downgrading libjs-jquery to version 
1.7.2+dfsg-3.2 immediately fixed the nzbget webinterface. This is with nzbget 
14.2+dfsg-2 btw, not running version 15 yet.

Thanks for the temporary workaround Mathew!


Kind regards,

Vincent van Leeuwen

Bug#801026: osgi-compendium: depends on obsolete libservlet2.5-java library

[Markus Koschany]

Am 05.10.2015 um 21:26 schrieb Neil Bartlett:
> This isn’t really possible. The osgi-compendium package is not just a program 
> or library; it represents a specification published by a standards body, the 
> OSGi Alliance. The specification supports the java servlet API 2.5 and above. 
> We cannot simply update to 3.1 since that could break any consumers using 2.5 
> — also the package would not comply with the published specification.
> 
> Neil Bartlett

Hello,

you contradict yourself by claiming that The OSGi Compendium 5
specification supports the Java servlet API 2.5 and above and in the
next sentence you claim it only supports 2.5.

I think your first part is correct. I quote from page 795 of the
specification:

"This Web Application Specification provides support for web
applications written to the Servlet 2.5
specification, or later"

So I see this more like a minimum requirement. I have also never
understood why we build-depend on libservlet2.5-java at all given the
fact that it is not needed at build-time. I would rather tend to
completely remove the build-dependency and the corresponding dependency
on libservlet2.5-java but not before I have checked that all
reverse-dependencies do not rely on this behaviour.

Can you provide an example what package in Debian would be negatively
affected if we started to build-depend/depend on libservlet3.1-java?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#793687: rsnapshot: regression fix: --rsh args

[Paul Muster]

tags 793687 patch
thanks

On Sun, 6 Sep 2015 12:55:32 Jonas Genannt  wrote:


The patch that is working is backported from upstream to the version in Jessie:



Could you please provide a stable update?


It would be really great if a fixed package could be provided for Jessie.


Thanks & Greetings,

Paul

Bug#798256: transition: hdf5

[Gilles Filippini]

Emilio Pozuelo Monfort a écrit le 05/10/2015 17:59 :
> Control: tag 798256 791067 + pending
> 
> On 05/10/15 17:13, Gilles Filippini wrote:
>> Hi,
>>
>> On Wed, 30 Sep 2015 10:04:48 +0200 Gilles Filippini  wrote:
>>> Emilio Pozuelo Monfort a écrit le 30/09/2015 00:37 :
 Control: tags -1 confirmed

 On 21/09/15 13:08, Gilles Filippini wrote:
> Ping.

 I think we can do this now. Go for it.
>>>
>>> Release 1.8.15-patch1+docs-4 upploaded to unstable.
>>
>> I have pending fixes for FTBFS on hppa, ppc64 and hurd-i386.
> 
> Looks like hppa and hurd built hdf5 a few hours ago.
> 
>> Should I
>> upload them now or do you think this isn't needed for the transition to
>> complete?
> 
> This isn't needed because those architectures aren't in testing. Note that 
> hdf5
> already migrated, but now we're waiting for the rest of the rdeps to migrate 
> so
> the old libhdf5-8 can get removed. Should happen in the next few days if there
> aren't any problems.

Great.
Please tell me in case of anything left blocking the transition.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#781952: RFS:complexity/1.2-1 [ITP] -- tool for analyzing the complexity of C program functions

[Dmitry Bogatov]

I keep getting 500 from mentors, so would you be so kind to take
from /srv/home/users/kaction-guest/public_git/complexity.git?

> > I would suggest using https in all the debian/copyright URLs.
I fixed, but duck(1) complains about gnutls error. No idea, w3m opens
just fine these urls.

> > gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..   -D_FORTIFY_SOURCE=2  -g
> - -O2 > -Werror=array-bounds -Werror=clobbered
> - -Werror=volatile-register-var > -Werror=implicit-function-declaration
> - -fPIE -fstack-protector-strong > -Wformat -Werror=format-security   -c
> - -o unistd.o unistd.c
> > unistd.c:2:0: warning: "_GL_UNISTD_INLINE" redefined #define
> > _GL_UNISTD_INLINE _GL_EXTERN_INLINE ^ In file included from
> > ../config.h:967:0, from unistd.c:1: ./unistd.h:139:0: note: this is
> > the location of the previous >
> definition
> > # define _GL_UNISTD_INLINE _GL_INLINE ^

Anything with _GL prefix is about gnulib and I would prefer to do not
touch it, unless strictly necessery.

> > ar:
> > 
> > ar cru libgnu.a fd-hook.o unistd.o xsize.o asnprintf.o
> > printf-args.o printf-parse.o vasnprintf.o ar: `u' modifier ignored
> > since `D' is the default (see `U')

Same.

> > $ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not 
> > find or open any of the paths given.' [src/complexity.c:211]:
> > (error) Memory leak: lines_scoring [src/complexity.c:67]: (error)
> > va_list 'ap' was opened but not
> closed > by va_end().

Fixed.

> Let me know how to do you want to proceed with them, and I'll followup
> with another review.

Yes, please review again.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes
X-Web-Site: nanlnhhunqer4xcy.onion


signature.asc
Description: Digital signature

Bug#800817: (no subject)

[ZenWalker]

sorry, I will do better next time :)

Bug#801063: world -- high-quality speech analysis/synthesis system on the basis of Vocoder.

[Tobias Platen]

Package: wnpp
Severity: wishlist

* Package name: world
  Version : 0.2.0~dfsg4
  Upstream Author : Masanori Morise 
* URL : http://ml.cs.yamanashi.ac.jp/world/english/
* License : BSD
  Programming Lang: C++
  Description : WORLD is a high-quality speech analysis/synthesis 
system on the basis of Vocoder.


WORLD was proposed to synthesize high-quality speech as natural as the 
input speech.
The purpose of WORLD is reducing the computational cost of 
TANDEM-STRAIGHT without deterioration.
WORLD is superior to TANDEM-STRAIGHT in implementing the real-time 
singing synthesis,
whereas it is inferior to TANDEM-STRAIGHT in manipulating consonant 
flexibly.
Since the concept of WORLD differs from that of TANDEM-STRAIGHT, you 
should select them based on your purpose.

Bug#801067: nfs-common: Remove or updated README.Debian.nfsv4

[Reuben Thomas]

Package: nfs-common
Version: 1:1.2.8-6ubuntu1.1
Severity: normal

The README.Debian.nfsv4 file is now rather old; is NFSv4 really still
considered experimental?

Parts of this file may be worth keeping (I’m not an expert!), but at least
that claim should be removed, and mention of kernel versions and patch sets.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  43250  status
1000241   tcp  59720  status
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = rrt
Nobody-Group = rrt
-- /etc/fstab --

-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (400, 'trusty-proposed'), (100, 'trusty-backports'), (90, 
'wily-updates'), (90, 'wily')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-63-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nfs-common depends on:
ii  adduser 3.113+nmu3ubuntu3
ii  initscripts 2.88dsf-41ubuntu6.2
ii  libc6   2.19-0ubuntu6.6
ii  libcap2 1:2.24-0ubuntu2
ii  libcomerr2  1.42.9-3ubuntu1.3
ii  libdevmapper1.02.1  2:1.02.77-6ubuntu2
ii  libevent-2.0-5  2.0.21-stable-1ubuntu1.14.04.1
ii  libgssglue1 0.4-2ubuntu1
ii  libkeyutils11.5.6-1
ii  libkrb5-3   1.12+dfsg-2ubuntu5.1
ii  libmount1   2.20.1-5.1ubuntu20.7
ii  libnfsidmap20.25-5
ii  libtirpc1   0.2.2-5ubuntu2
ii  libwrap07.6.q-25
ii  lsb-base4.1+Debian11ubuntu6
ii  mountall2.53
ii  rpcbind 0.2.1-2ubuntu2.2
ii  sysv-rc 2.88dsf-41ubuntu6.2
ii  ucf 3.0027+nmu1

Versions of packages nfs-common recommends:
ii  python  2.7.5-5ubuntu3

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

Versions of packages nfs-kernel-server depends on:
ii  libblkid1 2.20.1-5.1ubuntu20.7
ii  libc6 2.19-0ubuntu6.6
ii  libcap2   1:2.24-0ubuntu2
ii  libsqlite3-0  3.8.2-1ubuntu2.1
ii  libtirpc1 0.2.2-5ubuntu2
ii  libwrap0  7.6.q-25
ii  lsb-base  4.1+Debian11ubuntu6
ii  ucf   3.0027+nmu1

-- no debconf information

Bug#801068: audible ping

[Antoine Beaupré]

Package: oping
Version: 1.7.0-1
Severity: wishlist
Tags: patch

hi barak!

considering you like the prettyping patch to oping, and that Debian
was faster at including it than upstream, i thought you would like the
following one as well:

https://github.com/octo/liboping/pull/6

patch attached!

a.

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

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

Versions of packages oping depends on:
ii  libc6 2.19-18+deb8u1
ii  libncursesw5  5.9+20140913-1+b1
ii  liboping0 1.7.0-1
ii  libtinfo5 5.9+20140913-1+b1

oping recommends no packages.

oping suggests no packages.

-- no debconf information
>From b3dd77f89dc927ab3a877fb7d82850a1ceabf9e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Mon, 5 Oct 2015 16:09:38 -0400
Subject: [PATCH] add bell output on successful pings

the rationale here is that it's actually pretty hard to do this with a
regular ping. you need a silly shell loop and it doesn't always work
right everywhere, because the output of the system ping is
platform-dependant. it also buffers stdout in some weird ways sometimes.

therefore, i think it's a great addition to oping.

the purpose of this is that it can be useful to "hear" ping packets
come back when doing network diagnostics. obviously, this will be
useless in finding out *failed* hosts if multiple hosts are selected,
as any sucessful host will produce a beep. but it can nevertheless be
used to trace network cables or problems without looking at the
console. i also use audible pings to let me know when a hosts returns
after a reboot.

Note that I had to struggle quite a bit to make my terminal bell work,
the following articles were used to generate documentation on how to
make that work reliably:

https://askubuntu.com/questions/228096/terminal-bell-doesnt-ring

also see the following for the original inspiration for this:

http://catb.org/jargon/html/P/ping.html
https://groups.google.com/forum/#!msg/comp.sys.next/JDaeD8oqarU/v8xaDS8kXM0J
---
 src/mans/oping.pod | 44 
 src/oping.c| 13 -
 2 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/src/mans/oping.pod b/src/mans/oping.pod
index b609414..b8b8a5c 100644
--- a/src/mans/oping.pod
+++ b/src/mans/oping.pod
@@ -232,6 +232,50 @@ remainder.
 
 =back
 
+=item B<-b>
+
+Audible bell. Print a ASCII BEL character (\a or 0x07) when a packet
+is received before the timeout occurs. This can be useful in order to
+monitory hosts' connectivity without looking physically at the
+console, for example to trace network cables (start audible beep,
+disconnect cable N: if beep stops, the cable was in use) or to tell
+when a host returns from a reboot.
+
+This relies on the terminal bell to be functional. To enable the
+terminal bell, use the following instructions.
+
+=over 4
+
+=item
+
+the visual bell is disabled in your terminal emulator, with the +vb
+commandline flag or the following in your .Xresources:
+
+ XTerm*visualBell: false
+
+=item
+
+the PC speaker module is loaded in your kernel:
+
+ modprobe pcspkr
+
+=item
+
+X11 has the terminal bell enabled:
+
+ xset b on; xset b 100
+
+=item
+
+and finally, if you are using PulseAudio, that the module-x11-bell
+module is loaded with a pre-loaded sample defined in your pulseaudio
+configuration:
+
+ load-sample-lazy x11-bell /usr/share/sounds/freedesktop/stereo/complete.oga
+ load-module module-x11-bell sample=x11-bell
+
+=back
+
 =item B<-P> I
 
 Configures the latency percentile to report. I must be a number
diff --git a/src/oping.c b/src/oping.c
index 53602d3..4559f79 100644
--- a/src/oping.c
+++ b/src/oping.c
@@ -208,6 +208,7 @@ static double  opt_exit_status_threshold = 1.0;
 static int opt_show_graph = 1;
 static int opt_utf8   = 0;
 #endif
+static int opt_bell   = 0;
 
 static int host_num = 0;
 
@@ -649,7 +650,7 @@ static int read_options (int argc, char **argv) /* {{{ */
 
 	while (1)
 	{
-		optchar = getopt (argc, argv, "46c:hi:I:t:Q:f:D:Z:P:m:w:"
+		optchar = getopt (argc, argv, "46c:hi:I:t:Q:f:D:Z:P:m:w:b"
 #if USE_NCURSES
 "uUg:"
 #endif
@@ -781,6 +782,9 @@ static int read_options (int argc, char **argv) /* {{{ */
 opt_utf8 = 1;
 break;
 #endif
+			case 'b':
+opt_bell = 1;
+break;
 
 			case 'Z':
 			{
@@ -1566,6 +1570,13 @@ static void update_host_hook (pingobj_iter_t *iter, /* {{{ */
 #if USE_NCURSES
 		}
 #endif
+if (opt_bell) {
+#if USE_NCURSES
+			beep();
+#else
+			HOST_PRINTF ("\a");
+#endif
+}
 	}
 	else /* if (!(latency > 0.0)) */
 	{
-- 
2.1.4

Bug#801026: osgi-compendium: depends on obsolete libservlet2.5-java library

[Neil Bartlett]

> On 5 Oct 2015, at 21:03, Markus Koschany  wrote:
> 
> Am 05.10.2015 um 21:26 schrieb Neil Bartlett:
>> This isn’t really possible. The osgi-compendium package is not just a 
>> program or library; it represents a specification published by a standards 
>> body, the OSGi Alliance. The specification supports the java servlet API 2.5 
>> and above. We cannot simply update to 3.1 since that could break any 
>> consumers using 2.5 — also the package would not comply with the published 
>> specification.
>> 
>> Neil Bartlett
> 
> Hello,
> 
> you contradict yourself by claiming that The OSGi Compendium 5
> specification supports the Java servlet API 2.5 and above and in the
> next sentence you claim it only supports 2.5.

There is no contradiction… where did I claim that it only supports 2.5?

The specification supports users who depend on servlet 2.5 or above. That means 
the specification JAR compiles against the lowest version that it supports, 
i.e. 2.5.

> 
> I think your first part is correct. I quote from page 795 of the
> specification:
> 
> "This Web Application Specification provides support for web
> applications written to the Servlet 2.5
> specification, or later"
> 
> So I see this more like a minimum requirement. I have also never
> understood why we build-depend on libservlet2.5-java at all given the
> fact that it is not needed at build-time. I would rather tend to
> completely remove the build-dependency and the corresponding dependency
> on libservlet2.5-java but not before I have checked that all
> reverse-dependencies do not rely on this behaviour.

The source code for OSGi Compendium contains the type 
org.osgi.service.http.HttpService, which depends on types from the 
javax.servlet package. If the osgi-compendium package in Debian builds from 
Java sources then it certainly needs javax.servlet to be present on the 
compiler’s classpath, and therefore the dependency cannot be removed. On the 
other hand if it repackages pre-built JARs from elsewhere then I would agree 
that javax.servlet does not need to be present as a dependency.


> 
> Can you provide an example what package in Debian would be negatively
> affected if we started to build-depend/depend on libservlet3.1-java?

No I am not able to answer this.

> 
> Regards,
> 
> Markus
> 


Neil

Bug#800657: Please provide a vdpau-driver-all package and let libvdpau1 recommend it

[Andreas Beckmann]

Control: tag -1 pending

On 2015-10-02 09:52, Alexander Kurtz wrote:
> It would be great if libvdpau could provide a similar vdpau-driver-all
> package which could roughly look like this:

Sounds sensible.
Added in GIT.


Andreas

Bug#798773: postinst script handles comments in config file incorrectly

[Stephen Frost]

Greetings,

Any chance we could get this bug fixed?  Looks like a pretty
straight-forward change.

Is there anything I can do to help?

Thanks!

Stephen


signature.asc
Description: Digital signature

Bug#795509: fixed ?

[Mathieu Malaterre]

found 795509 0.7.9-5
fixed 795509 0.8.1a-1
thanks

Andreas,

Could you be a little bit more verbose:

https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=24;bug=795509

thx

Bug#794466: virtualbox: Virtualbox might not be suitable for testing

[Clemens Haupt Hohentrenk]

Package: virtualbox
Version: 5.0.4-dfsg-4
Followup-For: Bug #794466

Dear Maintainer,

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

   * What led up to the situation?

Updateing yesterday didn't help

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

Undating

   * What was the outcome of this action?

The virtual machine 'Deppi-505' has terminated unexpectedly during startup with 
exit code 1 (0x1).

   * What outcome did you expect instead?

Smooth working


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


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

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

Versions of packages virtualbox depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-22
ii  libcurl3-gnutls  7.44.0-2
ii  libgcc1  1:5.2.1-17
ii  libgsoap72.8.22-1
ii  libpng12-0   1.2.50-2+b2
ii  libpython2.7 2.7.10-4
ii  libsdl1.2debian  1.2.15-11
ii  libssl1.0.0  1.0.2d-1
ii  libstdc++6   5.2.1-17
ii  libvncserver10.9.10+dfsg-3
ii  libvpx2  1.4.0-4
ii  libx11-6 2:1.6.3-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxext6 2:1.3.3-1
ii  libxml2  2.9.2+zdfsg1-4
ii  libxmu6  2:1.1.2-1
ii  libxt6   1:1.1.4-1+b1
ii  python   2.7.9-1
ii  python2.72.7.10-4
pn  python:any   
ii  virtualbox-dkms  5.0.4-dfsg-4
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  10.6.8-1
ii  libqt4-opengl 4:4.8.7+dfsg-3
ii  libqtcore44:4.8.7+dfsg-3
ii  libqtgui4 4:4.8.7+dfsg-3
ii  virtualbox-qt 5.0.4-dfsg-4

Versions of packages virtualbox suggests:
ii  vde22.3.2+r586-2
ii  virtualbox-guest-additions-iso  5.0.4-1

-- Configuration Files:
/etc/default/virtualbox changed:
LOAD_VBOXDRV_MODULE=1
SHUTDOWN_USERS="yx"
SHUTDOWN=poweroff


-- no debconf information

Fehlercode:
NS_ERROR_FAILURE (0x80004005)
Komponente:
MachineWrap
Interface:
IMachine {f30138d4-e5ea-4b3a-8858-a059de4c93fd}

Bug#800910: [Vmdebootstrap-devel] Bug#800910: vmdebootstrap: creates /etc/inittab even if sysvinit is not installed

[Neil Williams]

tag 800910 - patch
tag 800910 + moreinfo
thanks

On Sun, 04 Oct 2015 23:19:15 +0200
Christian Seiler  wrote:

> Package: vmdebootstrap
> Version: 0.11-1
> Severity: normal
> Tags: patch upstream
> 
> Dear Maintainers,
> 
> while using vmdebootstrap to create VM images for the use with
> autopkgtest, I've stumbled upon the following problem:
> 
>  - I want to do integration testing, and part of that is to test the
>package with different init systems.

The most deterministic way to do that is to have separate images and
change the test harness to match. Otherwise, you are not actually
testing with different *clean* init systems, you are testing one clean
and one potentially dirty init system which would have vestiges of the
old one left behind.

Put it this way, if you reversed the sequence, your tests could be
rendered invalid. The way you are describing this, you are not actually
testing against sysvinit, you are testing against a system which has
been converted from systemd to sysvinit. The primary issue a lot of
people want tested is to run on a system which was sysvinit, stayed
as sysvinit and never had systemd installed as init. To do that, a
second image built for wheezy with the shim package and then upgraded
to jessie would be the only viable candidate for a valid test of the
kind of system that users are actually running. You should not rely on
the purge being 100% effective (or else have a third image which has
been converted - once - and then upgraded).

>  - The default test is run with the default init system, systemd. That
>works fine.
> 
>  - For testing sysvinit, I run
>  apt-get -y --purge --install sysvinit-core
>inside the VM, then reboot the VM.
> 
>  - After that, I would run that test again with sysvinit as the init
>system.

Whatever process calls the apt-get command also needs to make the
changes necessary - similar to how the customisation support works.

> I've attached a patch that does the following:
> 
>  - if /etc/inittab exists, nothing changes
> 
>  - if /etc/inittab doesn't exist, /etc/inittab.tail is created
> instead, and an init script is installed that will update /etc/inittab
>and append the /etc/inittab.tail file once it's booted under
>sysvinit for the first time (will do nothing under systemd)

It's not about making changes in vmdebootstrap to change how the system
works after a successfully built image has booted successfully.
Changing the init system is a specialised task, it's up to the test
harness to ensure that that kind of task actually works *and* that it
represents real systems. It's outside the scope of vmdebootstrap -
unless the presence of absence of the file has any implication for how
the image itself is first built or first booted. If that is not a
problem, then this bug report can be closed.

Rejecting the patch - there is no justification for vmdebootstrap to
carry a hardcoded init file in this way. There are enough problems with
the extlinux support doing it.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgptORssX4VZ6.pgp
Description: OpenPGP digital signature

Bug#800930: ITP: ratt -- Rebuild All The Things!

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: ratt
  Version : 0.0~git20150816.0.b060319-1
  Upstream Author : Michael Stapelberg
* URL : https://github.com/debian/ratt
* License : MIT
  Programming Lang: Go
  Description : Rebuild All The Things!

 ratt (“Rebuild All The Things!”) operates on a Debian .changes file of a
 just-built package, identifies all reverse-build-dependencies and rebuilds
 them with the .debs from the .changes file.
 .
 The intended use-case is, for example, to package a new snapshot of
 a Go library and verify that the new version does not break any other
 Go libraries/binaries.

Bug#798672: qdox: please upgrade qdox to version 2.x

[Markus Koschany]

owner 798672 !
thanks

I'm working on an update of qdox to version 2.0-M3.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#800931: xserver-xorg-video-intel: needs xorg-video-abi-18, but not available

[Jakobus Schürz]

Package: xserver-xorg-video-intel
Version: 2:2.99.917-2
Severity: important

Dear Maintainer,

I tried to update my jessie on stretch. But package couldn't be
installed in case of abi-mismatch.

# apt-get install xserver-xorg-video-intel
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 xserver-xorg-video-intel : Depends: xorg-video-abi-18
 E: Unable to correct problems, you have held broken packages.


# apt-get install xorg-video-abi-18
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package xorg-video-abi-18 is a virtual package provided by:
  xserver-xorg-core 2:1.16.4-1 [Not candidate version]

  E: Package 'xorg-video-abi-18' has no installation candidate

best regards

Jakob

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

lrwxrwxrwx 1 root root 13 Feb 28  2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2388040 Aug 11 10:53 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of 

Bug#800674: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#800674: Embedded feature with SLOB-allocation fails, no boot)

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 03 Oct 2015 01:06:04 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:

> This is still not the right place to report bugs in SLOB, nor to ask
> for support with configuring your kernel.  Please stop doing this.
> 
> Ben.
> 
> -- 

I was not asking for support regarding kernel-configuration, I guess nobody 
would.
It's pretty much like if you don't know how to configure the kernel-source, you 
clearly
have no need to build your own custom kernel.

I start wondering though, why I am constantly receiving negative replies from 
you,
because you have to give *some*explanation* on ticket-close?

It's not ridiculous at all, but, well _*negative*_.

I want to give you an expample now of how to formulate this in a positive way.

Thanks a lot, dear reporter, we appreciate you are donating some of your 
precious time in
order to improve our distribution, we will take the necessary steps to make 
proper use
of the information you supplied.

Or:

Sorry, dear reporter, this and that are the right places to report your problem.

Got it?? Be positive !
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlYSEZUACgkQ5+rBHyUt5wsUDgCfct6rkfdBNcgV1L92VasXiQy2
flEAnRFRu/HMeYpSewnckwtP5Zhd14M/
=heMR
-END PGP SIGNATURE-

Bug#794429: RFA: rspamd

[Mikhail Gusarov]

Hi Aurélien,

Definitely. Feel free to take over.

Regards, Mikhail.

On Sun, 4 Oct 2015, at 23:24, Aurélien Gérôme wrote:
> Hi Mikhail,
> 
> If this is still all right with you, I am interested to bring rspamd
> to the latest upstream release with non-native packaging.  So far,
> rspamd seems to satisfy my use case in replacement of a dead and
> buggy dspam, so I am willing to pitch in.
> 
> Regards,
> -- 
>  .''`.   Aurélien Gérôme
> : :'  :
> `. `'`   Debian Developer
>   `- Unix Sys & Net Admin

Bug#799078: uploaders, suggests, extra binary packages should be kept

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

this will help us avoid lot of repetitive work when refreshing old
packages
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWEjBWAAoJEM4fnGdFEsIqinAP/28PEozhERYY4kNOqSVcCX9/
MFgUDMFvt0smz5G1VwtCjujAgLB0EshkRxylAlaDxCkW7qyrxAE/MMkhXuU7Zbf7
bCTrJd1QF1kHP3XN+hlxnqc2hVT8i0QEwNfC2OyIuk7f3yojcADh5XoDrI+5K2vf
KUTloVEnochPIswbhuKsviVMsayeE0svxy7Kq9Ild3RVKDz3tG7EKS3lty3cJtdM
6hw9zbmFBFo+Z1M19gz+3Z71kFAcNiZndI6Jbu53e5Af7hCxT5dpWwgCA9mf7pe0
15XtjXXYkXjFHNENWg/VGTmnx2VOL5brlIY4ibOKalnsTEjrUZsP/lZ9HUuX25zt
wBxR6ATf6+BQt+Pb3zXd9NDGvJz3Juw9sKqE/stdxmFDDBhAT+akLVNTJo+AlC+0
JnhokpU3TGsFJcg2cBpUBaweABoiRz31unYZtTmEWTI8fZylzVleJTf5zPxE5wJC
P1YmN+5OG8qGBj/zj0ONL2bBeTdM0RS+VoJpnyAB6/bAyoN3j8dGQAmmUdcq9931
xtKvJmo9T0cgHZkmw0jlNMifWtalGeIm3zMEYL6PhuGt2t9EbM5fHB9K7ph+EKZ5
pSAAItqZJCzFyI0AWLpXsLQRQI283RX8SXNg0c0UZ5ZdFrs5PRtRWg1LyPIqbXZQ
N3sPyp7XtxUun9gAgQvg
=s1nc
-END PGP SIGNATURE-

Bug#780022: BUG: triggered 'if (axnum >= dev->valuator->numAxes)'

[Sebastien Bacher]

The error seems similar to the one fixed in
http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=38e107a39fb4a0b630ee5adb5870c91dbc27abde

Bug#800779: gstreamer1.0-libav:amd64: The gstreamer1.0-libav video encoders segfault

[Francois Gouget]

On Sat, 3 Oct 2015, Sebastian Dröge wrote:
[...]
> On Sa, 2015-10-03 at 18:21 +0100, Sebastian Dröge wrote:
> 
> > > $ gst-launch-1.0 videotestsrc num-buffers=40 ! videoconvert !
> > > avenc_mjpeg ! filesink location=/dev/null
> > 
> > This is a different problem, it looks like a race condition in ffmpeg
> > or something. It works if you use max-threads=1 in avenc_mjpeg.
> 
> And this one is fixed by
> http://cgit.freedesktop.org/gstreamer/gst-libav/commit/?id=eedefc9f6bd19f1c86b43d1fcc31a203b4ecea10

Thanks!
With both patches all appears good.


-- 
Francois Gouget   http://fgouget.free.fr/
Indifference will certainly be the downfall of mankind, but who cares?

Bug#799368: Man-page: description of -e option contradicts itself

[Justin B Rye]

On Fri, Sep 18, Andrew Shadura wrote:
> Karl E. Jorgensen wrote:
>> ''You should include "event" here, but you must not do so.'' 
>> Huh??  To include or to not include I'm confused, and I think most
>> other readers would be too :-)
> 
> I'm not sure I understand what exactly is confusing you :)

I'm not the bug submitter, but I see what's confusing him.  Just as he
says, the manual page for brightd has some rather confusing text in the
description of the -e option:

# -e n
#
#  Filter used event sources by POSIX extended regexp n (for example,
#  use "i8042.+event" on intel platforms to avoid having HDAPS taken
#  into account) You should include "event" here, but you must not do
#  so.

Look at that last sentence.
#  You should include "event" here, but you must not do so.

Grammatically, that clause "you must not do so" can be interpreted
only one way: it's saying

#  you SHOULD: include "event" here, but
#  you MUST:   not include "event" here.

In other words, this action is both requested and prohibited.

I suspect that the writer of the manual got confused about the correct
way to negate a "must", and intended it to mean:

#  You should probably include "event" here, but it is not mandatory.

The secondary problem is that it's completely unclear how I would
"include 'event' here" - does "event" mean the literal string 'event'
or the name of an ACPI event type or what?

The whole man page is full of grammatical problems, but the rest of
them are less serious than this.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#800936: ITP: ipykernl -- IPython kernel for Jupyter

[Julien Puydt]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org

* Package name: ipykernel
  Version : 4.0.3
  Upstream Author : Jupyter Development Team
* URL : https://github.com/ipython/ipykernel
* License : BSD-3-clause
  Programming Lang: Python
  Description : IPython kernel for Jupyter
 This software component provides an IPython kernel, which will hook
 itself into Jupyter.

Cheers,

Snark on #debian-python

Bug#800912: Marking bug as pending

[Vasudev Kamath]

Control: tag -1 +pending

Hi John,

Thanks for the report, I've updated the symbols file accordingly and
pushed change to the git repository on collab-maint.¹

¹ http://anonscm.debian.org/cgit/collab-maint/zimlib

Cheers,

Bug#800087: closed by Michael Biebl <bi...@debian.org> (Re: Bug#800087: systemd lists running daemons as failed after reboot)

[Michael Biebl]

Am 05.10.2015 um 01:48 schrieb James Bottomley:
> On Sun, 2015-10-04 at 23:06 +, Debian Bug Tracking System wrote:
>> Well, this is apparently an apache configuration problem, causing the
>> service to return a non-zero exit code.
>>
>> Once you fix that, the service should not be marked as failed.
> 
> That's pretty obviously an incorrect deduction, isn't it?  If it were a
> config file problem leading to the control process erroring out then the
> manual systemctl start apache would also fail; but, as you can see from
> the description in the original report, it doesn't.

You might need to have give apache more time to start up. Maybe 20 secs
is not enough since during boot there is a lot of other I/O going on and
the apache control process kills itself prematurely:


> Oct 03 10:45:06 bedivere apache2[693]: Starting web server: apache2AH00180: 
> WARNING: MaxRequestWorkers of 20 exceeds ServerLimit value of
> Oct 03 10:45:06 bedivere apache2[693]: 5 servers, decreasing 
> MaxRequestWorkers to 5.
> Oct 03 10:45:06 bedivere apache2[693]: To increase, please see the 
> ServerLimit directive.
> Oct 03 10:45:42 bedivere apache2[693]: failed!
> Oct 03 10:45:42 bedivere apache2[693]: The apache2 instance did not start 
> within 20 seconds. Please read the log files to discover problems ... 
> (warning).
> Oct 03 10:45:42 bedivere systemd[1]: apache2.service: Control process exited, 
> code=exited status=1




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



signature.asc
Description: OpenPGP digital signature

Bug#800932: ITP: andi -- Efficient Estimation of Evolutionary Distances

[Andreas Tille]

Hi Fabian,

On Mon, Oct 05, 2015 at 10:21:12AM +0200, Fabian Klötzl wrote:
> I intend to package andi for Debian. Even though "andi" is a pretty
> generic name there is no package with that name, yet. Is it OK to call
> the package "andi", too, or should it be "bioandi" or somthing similar?

I guess for non-German speakers andy might be a random 4 letter
combination and nobody will confuse it with the tyical nickname of
a German Andreas. :-)

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#797765: (no subject)

[Johannes Zarl-Zierl]

On Friday 02 October 2015 16:13:24 Lisandro Damián Nicanor Pérez Meyer wrote:
> This really happens because qtcreator is using the QtQucik2 aka
> "declarative" stuff. The QtQuick1 stuff is being kept only for old
> not-yet-ported stuff.

Thanks for the explanation.

In this case it would be nice if the package would at least show up in a 
search for qtquick. Is it possible to change the package description of 
qtdeclarative5-dev to something like this:

>> This package contains the header development files for building some 
>>  
>>
>> Qt 5 applications using Qt 5 declarative (aka QtQuick2) headers.

Another way to make the situation more transparent to users would be to add 
something like this to the package description of qtquick1-5-dev:

>> In order to build Qt Quick 2 applications on Qt5, you need to install the
>> package qtdeclarative5-dev, instead.

Cheers,
  Johannes

Bug#800939: ITP: python-openstackdocstheme -- extension support for Sphin OpenStack doc

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-openstackdocstheme
  Version : 1.2.2
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/openstackdocstheme
* License : Apache-2.0
  Programming Lang: Python
  Description : extension support for Sphin OpenStack doc

 Theme and extension support for Sphinx documentation that is published to
 docs.openstack.org. Intended for use by OpenStack projects.

Bug#800087: closed by Michael Biebl <bi...@debian.org> (Re: Bug#800087: systemd lists running daemons as failed after reboot)

[Michael Biebl]

Am 05.10.2015 um 10:41 schrieb Michael Biebl:
> Am 05.10.2015 um 01:48 schrieb James Bottomley:
>> On Sun, 2015-10-04 at 23:06 +, Debian Bug Tracking System wrote:
>>> Well, this is apparently an apache configuration problem, causing the
>>> service to return a non-zero exit code.
>>>
>>> Once you fix that, the service should not be marked as failed.
>>
>> That's pretty obviously an incorrect deduction, isn't it?  If it were a
>> config file problem leading to the control process erroring out then the
>> manual systemctl start apache would also fail; but, as you can see from
>> the description in the original report, it doesn't.
> 
> You might need to have give apache more time to start up. Maybe 20 secs
> is not enough since during boot there is a lot of other I/O going on and
> the apache control process kills itself prematurely:
> 

let me rephrase that: try to find out why apache does not start up
properly within 20 secs (e.g. due to missing ressources) and then fix
that or increase the limit.



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



signature.asc
Description: OpenPGP digital signature

Bug#800884: add basic details about RTC services

[Raphael Hertzog]

Hi Daniel,

On Sun, 04 Oct 2015, Daniel Pocock wrote:
> This patch adds to chapter 11, giving a brief introduction to RTC
> services on Debian

We have a section dedicated to XMPP and setting up ejabberd in Chapter
13 already:
https://debian-handbook.info/browse/jessie/ch13s07.html#idm140062055217232

I think you should put your section there, either by separating XMPP
from the rest so that you can keep the current section or by merging
the existing section in an expanded section covering real time
communication.

I would need that rather quickly if you want to make it to the
jessie edition.

> +  Prosody

You don't even mention Prosody in your text. You might want to mention it
as an alternative to ejabberd (in a sidebar possibly?) in the current
section about IM.

> +The Falcot Corp administrators decided that they would use a
> +SIP proxy and not a full PBX like Asterisk at the network boundary
> +because they wanted to maximize connectivity and stability while also
> +having a relatively simple configuration.  They chose the repro SIP proxy
> +from the reSIProcate project because it has been built from the ground up

reSIProcate

> +to support IPv6 and TLS and it also has support for WebRTC.  In the 
> future,
> +they intend to setup an internal PBX using Asterisk, however, all calls 
> going
> +to the Asterisk server will be routed through the SIP proxy.
> +
> +Comprehensive details of how to plan and install these services
> +are available in the Real-Time Communications Quick Start Guide

 around the title

> +which includes examples specific to Debian.
> +http://rtcquickstart.org"/>

Otherwise it looks good to me.

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#800077: virtualbox: Cannot install 5.0.4-dfsg-3 with just modules

[candeb]

Yes that is what I meant.
Thanks !

I.

- Mail original -
De: "Gianfranco Costamagna" 
À: can...@free.fr, 800...@bugs.debian.org
Cc: 800...@bugs.debian.org, "Ritesh Raj Sarraf" 
Envoyé: Dimanche 4 Octobre 2015 23:13:25
Objet: Re: Bug#800077: virtualbox: Cannot install 5.0.4-dfsg-3 with just modules

Hi, do you mean changing this line from
Depends: adduser, ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}, 
virtualbox-dkms (>= ${source:Version}) | virtualbox-source (>= 
${source:Version}) | virtualbox-modules (>= ${source:Version})


to 

Depends: adduser, ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}, 
virtualbox-dkms (>= ${source:Version}) | virtualbox-source (>= 
${source:Version}) | virtualbox-modules

seems legit to me,

cheers,

G.





Il Domenica 4 Ottobre 2015 12:03, "can...@free.fr"  ha scritto:
Hi again,

Sorry, I should have thought about it earlier but only realised it when I still 
couldn't upgrade without the sources : Debian does not allow versioned 
dependencies on virtual package names.  In other words, if you put any version 
requirement on virtualbox-modules it will only accept a package actually named 
virtualbox-modules with an appropriate version, a "provides" will not be 
accepted.

Will you find it acceptable to remove the version constraints from the 
"virtualbox-modules" dependency ?  I think this would not change much from your 
point of view - a user who is competent enough to compile and install separate 
module packages would know what to do if virtualbox complains the installed 
modules are for an older version, no ?

Cheers,
I.



- Mail original -
De: "Gianfranco Costamagna" 
À: can...@free.fr
Cc: 800...@bugs.debian.org, "Ritesh Raj Sarraf" 
Envoyé: Lundi 28 Septembre 2015 09:00:13
Objet: Re: Bug#800077: virtualbox: Cannot install 5.0.4-dfsg-3 with just modules

Hi


>Thanks, but I beg to disagree : you need
>
>virtualbox-dkms OR virtualbox-source  ** OR virtualbox-modules **
>
>I compile modules on one machine and use them on several others.  Why force 
>me to install the module sources, kernel headers, and all the rest if I
>already have the compiled modules ?


sure, this is a perfectly valid use-case :)
http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=41a45bc76907ad2921e4ad50fc6c1b8fba45fad4

committed, on git, can you please tell me if it works for you?


I also changed the dependency to >= instead of =, because the kernel modules 
should work even if from
other virtualbox versions.

(I'm specially thinking about getting a new dkms and keep an old virtualbox, 
just because the kernel has been upgraded)

@Ritesh, how do you feel about that commit?

cheers,

Gianfranco

Bug#800776: [Debian-ha-maintainers] Bug#800776: cluster-glue: please make the build reproducible

[Christoph Berg]

Re: Reiner Herrmann 2015-10-03 <560fdee9.2090...@reiner-h.de>
> +export SOURCE_DATE_EPOCH = $(shell date -d "$$(dpkg-parsechangelog -SDate)" 
> +%s)

Hi,

thanks for the patch!

However, shouldn't this be set from the toolchain? Builds are only
reproducible in practise now using a patched toolchain, and from what
I got the plan is to make the toolchain set this variable, so I'd
really expect the current reproducible.debian.net toolchain to expose
this variable as well, even if it's not clear which bit (dpkg,
debhelper, makefile include snippet ...) will set it in future.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#800932: ITP: andi -- Efficient Estimation of Evolutionary Distances

[Fabian Klötzl]

Package: wnpp
Severity: wishlist
Owner: "Fabian Klötzl" 

* Package name: andi
  Version : 0.9.4
  Upstream Author : Fabian Klötzl 
* URL : https://github.com/EvolBioInf/andi
* License : GPL
  Programming Lang: C
  Description : Efficient Estimation of Evolutionary Distances

This is the andi program for estimating the evolutionary distance between 
closely related genomes. These distances can be used to rapidly infer 
phylogenies for big sets of genomes. Because andi does not compute full 
alignments, it is so efficient that it scales even up to thousands of bacterial 
genomes.

I am the upstream author and think this program is useful for the scientific 
community to rapidly infer phylogenies. The Debian package will be maintained 
as part of the Debian Med team.

Bug#797804: pgadmin3 segfaults after rightclick

[Christoph Berg]

Re: Marc F. Neininger 2015-10-04 
<1395670906.34206.1443938071980.javamail.open-xcha...@oxbaltgw02.schlund.de>
> Program received signal SIGSEGV, Segmentation fault.
> __lll_unlock_elision (lock=0x132c5e0, private=0)

> Hier der backtrace vom Segfault. Hilft das was?

Thanks.

It's still the same low-level instruction deep inside the guts of wx.
I'll ping the pgadmin3 developers again, maybe they have an idea.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature

Bug#795509: fixed ?

[Andreas Beckmann]

On 2015-10-05 08:27, Mathieu Malaterre wrote:
> Could you be a little bit more verbose:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=24;bug=795509

The bts gets confused if a bug is found+fixed in the same version,
treating it as unfixed (and never archiving the bug). The preferred way
to close an "invalid" bug is with no fixed version.


Andreas

Bug#691627: XFCE4 - switch user - without Gnome's Dependencies Vortex

[Andreas Neudecker]

Package: xfswitch-plugin
Version: 0.0.1-5
Followup-For: Bug #691627

I am surprised that this chain of GNOME dependencies still exists with
xfswitch-plugin. If it is only due to the gdmflexiserver that is not in
lightdm, there may be a simple solution:

When I switched from GNOME2 to XFCE several years ago I required a user
switching option. On the web somewhere I found a very simple script that
provides a drop-in replacement for gdmflexiserver. It is so short that I can
just copy-n-paste it here:

8<

#!/bin/sh
#
# Copyright (C) 2011 Canonical Ltd
# Author: Michael Terry 
#
# This program is free software: you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free Software
# Foundation, version 3 of the License.
#
# See http://www.gnu.org/copyleft/gpl.html for the full text of the license.

if [ -z "$XDG_SEAT_PATH" ]; then
  # something went wrong
  exit 1
fi

dbus-send --system --type=method_call --print-reply
--dest=org.freedesktop.DisplayManager $XDG_SEAT_PATH
org.freedesktop.DisplayManager.Seat.SwitchToGreeter

>8

May be this script could replace the gdm3 dependency in xfswitch?

I simply put this in /usr/local/bin and it works for me on several machines
running vanilla Debian (testing) or Linx Mint Debian Edtion 1 & 2 (LMDE1,
LMDE2), respectively. I use lightdm, except on one machine, where after upgrade
to LMDE2 lightdm behaved weirdly, so I replaced it with MDM; but the
gdmflexiserver script works fine there, too.

I am not sure where I found this script when I first used it. But today, there
are:

https://code.launchpad.net/~mterry/lightdm/gdmflexiserver
and https://code.launchpad.net/~mterry/lightdm/gdmflexiserver-fix





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

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

Bug#800933: gem2deb should test if git is used to list files in gemspec when metadata.yml is not present

[Pirate Praveen]

package: gem2deb
version: 0.21.1

this will lead to creating packages without a gemspec.



signature.asc
Description: OpenPGP digital signature

Bug#800935: pandoc: Possible dependency issue on pandoc-data?

[Oleksandr Gavenko]

Package: pandoc
Version: 1.12.4.2~dfsg-1+b14
Severity: normal

  $ apt-cache show pandoc
  Package: pandoc (Installed)
  ...
  Depends: pandoc-data, libc6 (>= 2.14), libffi6 (>= 3.0.4), libgmp10,
 liblua5.1-0, libpcre3 (>= 1:8.35), libyaml-0-2, zlib1g (>= 1:1.1.4)

I you see there are no exact match for 'pandoc-data' version. Is that correct?

When I update 'pandoc' package aptitude doesn't force to update 'pandoc-data'.

-- 
Best regards!

Bug#797881: QNAP TS-219P II: qcontrol no longer works after upgrading to linux-image-4.1.0-0.bpo.1-kirkwood

[Ian Campbell]

On Sun, 2015-10-04 at 22:21 +0100, Ben Hutchings wrote:
> On Sun, 2015-10-04 at 14:04 +0100, Ian Campbell wrote:
> > On Thu, 2015-09-03 at 12:20 +0200, Robert Schlabbach wrote:
> > > Package: linux-image-4.1.0-0.bpo.1-kirkwood
> > > Version: 4.1.3-1~bpo8+1
> > >  
> > > After installing this Linux kernel on my QNAP TS-219P II, qcontrol no
> > > longer works:
> > >  
> > > 1. The status LED remains in red/green blink mode (as set by the boot
> > > loader). It should be set to solid green when the kernel is loaded.
> > > 2. The buzzer does not buzz. It should buzz when the kernel is loaded
> > > and when the kernel is shutting down.
> > >  
> > > Removing and reinstalling the qcontrol package did not help.
> > 
> > I suspect this is due to the device path for the input node changing
> > from /dev/input/by-path/platform-gpio_keys-event to /dev/input/by
> > -path/platform-gpio-keys-event. With the version of qcontrol in Jessie
> > it won't even start if it can't find the device, even though it can do
> > many of its core things without it (the node is for button input only).
> 
> The change seems to have been in the other direction.

Right.

> > This is fixed by qcontrol 0.5.4-4 in testing (both looking for old and
> > new names, as well as not treating failure to find either as a
> > catastrophe), but for Jessie you can just edit the path in
> > /etc/qcontrol.conf.
> > 
> > If that works for you then it might be worth uploading an updated
> > qcontrol to backports.
> 
> I think the name change in the kernel should be reverted (not just in
> Debian, but upstream) since it broke existing userland.

I agree, I did mention this upstream at the time this was first
discovered[0] and the consensus seemed to be that this would be hard to fix
(or at least no one knew how).

> Presumably that would be:

I don't think DTB node names generally have any actual meaning and the
gpio_keys is the module name (which the kernel has normalised with "tr -
_", like it generally does), compared with the older board file based stuff
which was, I suppose, non-modular or otherwise hard coded somewhere.

It happened enough releases ago now that I think it is unlikely to change
back :-/. I probably should have chased harder at the time.

Ian.

[0] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/2237
91.html and some relevant replies:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224933.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/225917.html

> 
> --- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
> +++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
> @@ -32,7 +32,7 @@
>   };
>   };
>  
> - gpio_keys {
> + gpio-keys {
>   compatible = "gpio-keys";
>   #address-cells = <1>;
>   #size-cells = <0>;
> --- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
> +++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
> @@ -42,7 +42,7 @@
>   };
>   };
>  
> - gpio_keys {
> + gpio-keys {
>   compatible = "gpio-keys";
>   #address-cells = <1>;
>   #size-cells = <0>;
> --- END ---
> 
> Ben.
> 

Bug#789133: transition: ocaml 4.02.3

[Stéphane Glondu]

Le 30/09/2015 19:21, Emilio Pozuelo Monfort a écrit :
>> Now that gcc-5 migrated, can anyone give an ETA for the OCaml transition?
> 
> Has the situation improved wrt the last status update? Can you give an update?

plplot has been removed from testing. No other improvements, but I
believe we can proceed with the transition. Blocking packages are few
(only 2 not maintained by Debian OCaml Maintainers, virt-top and
zeroinstall-injector) and I think they can be (temporarily) removed from
testing if needed.

Cheers,

-- 
Stéphane

Bug#800937: fcml ftbfs on armel

[Matthias Klose]

Package: src:fcml
Version: 1.1.1-2
Severity: serious
Tags: sid stretch

fcml ftbfs on armel (built before there), failing the tests.

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

It also ftbfs on armhf and powerpc, and on Ubuntu only on i386

https://launchpad.net/ubuntu/+source/fcml/1.1.1-2

Some issue with 32bit little endian targets?

Bug#800938: kodi: segfault on start

[Vladmimir Stavrinov]

Package: kodi
Version: 15.2~rc1+dfsg1-2
Severity: normal

Dear Maintainer,

Won't start. Crash on start. See log.


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

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

Versions of packages kodi depends on:
ii  kodi-bin   15.2~rc1+dfsg1-2
ii  kodi-data  15.2~rc1+dfsg1-2

kodi recommends no packages.

kodi suggests no packages.

-- no debconf information
## Kodi CRASH LOG ###

 SYSTEM INFO 
 Date: Mon Oct  5 11:51:22 MSK 2015
 Kodi Options: 
 Arch: x86_64
 Kernel: Linux 4.2.0-1-amd64 #1 SMP Debian 4.2.1-2 (2015-09-27)
 Release: Debian GNU/Linux
## END SYSTEM INFO ##

### STACK TRACE #
=>  Core file: /home/vs/core (2015-10-05 11:51:22.759834897 +0300)
=
[New LWP 27863]
[New LWP 27874]
[New LWP 27873]
[New LWP 27875]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/x86_64-linux-gnu/kodi/kodi.bin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x01bee860 in ?? ()
[Current thread is 1 (Thread 0x7f0bf4eb0980 (LWP 27863))]

Thread 4 (Thread 0x7f0bcad79700 (LWP 27875)):
#0  0x7f0bea0a252d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f0bee42a831 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x7f0bee41be51 in pa_mainloop_poll () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x7f0bee41c4ee in pa_mainloop_iterate () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#4  0x7f0bee41c5a0 in pa_mainloop_run () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#5  0x7f0bee42a7c6 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#6  0x7f0be25b9ff8 in ?? () from 
/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-7.0.so
#7  0x7f0bf27a90a4 in start_thread (arg=0x7f0bcad79700) at 
pthread_create.c:309
#8  0x7f0bea0ab06d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7f0bc7579700 (LWP 27873)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
#1  0x00978f57 in ActiveAE::CActiveAE::Process() ()
#2  0x0113ed0f in CThread::Action() ()
#3  0x0113efd2 in CThread::staticThread(void*) ()
#4  0x7f0bf27a90a4 in start_thread (arg=0x7f0bc7579700) at 
pthread_create.c:309
#5  0x7f0bea0ab06d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f0bcb57a700 (LWP 27874)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:143
#1  0x7f0bee42ae18 in pa_threaded_mainloop_wait () from 
/usr/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x0099791c in CAESinkPULSE::AddPackets(unsigned char**, unsigned 
int, unsigned int) ()
#3  0x0097ae56 in 
ActiveAE::CActiveAESink::OutputSamples(ActiveAE::CSampleBuffer*) ()
#4  0x0097c022 in ActiveAE::CActiveAESink::StateMachine(int, 
Actor::Protocol*, Actor::Message*) ()
#5  0x0097ca57 in ActiveAE::CActiveAESink::Process() ()
#6  0x0113ed0f in CThread::Action() ()
#7  0x0113efd2 in CThread::staticThread(void*) ()
#8  0x7f0bf27a90a4 in start_thread (arg=0x7f0bcb57a700) at 
pthread_create.c:309
#9  0x7f0bea0ab06d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f0bf4eb0980 (LWP 27863)):
#0  0x01bee860 in ?? ()
#1  0x00746625 in CMediaSourceSettings::Clear() ()
#2  0x00c991e1 in CSettingsManager::OnSettingsUnloaded() ()
#3  0x00c99e43 in CSettingsManager::Unload() ()
#4  0x00c9d2de in CSettingsManager::Clear() ()
#5  0x00730cfd in CSettings::Uninitialize() ()
#6  0x0073115f in CSettings::~CSettings() ()
#7  0x7f0be9ffcbc9 in __run_exit_handlers (status=-1, listp=0x7f0bea3685a8 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#8  0x7f0be9ffcc15 in __GI_exit (status=) at exit.c:104
#9  0x7f0be9fe6b4c in __libc_start_main (main=0x6ccc40 , argc=1, 
argv=0x7ffd558646f8, init=, fini=, 
rtld_fini=, stack_end=0x7ffd558646e8) at libc-start.c:321
#10 0x00716b39 in _start ()
# END STACK TRACE ###

# LOG FILE ##

11:51:21 T:139689330411904  NOTICE: special://profile/ is mapped to: 
special://masterprofile/
11:51:21 T:139689330411904  NOTICE: 

Bug#800940: dulwich doesn't seem to be ready for 64bit architectures

[Matthias Klose]

Package: src:dulwich
Version: 0.11.2-1
Severity: important
Tags: sid stretch

seen on the Ubuntu buildds at

Function `PyString_FromStringAndSize' implicitly converted to pointer at 
dulwich/_objects.c:52
Function `PyString_AS_STRING' implicitly converted to pointer at 
dulwich/_objects.c:212

Function `Py_InitModule3' implicitly converted to pointer at 
dulwich/_objects.c:256
Function `PyString_FromString' implicitly converted to pointer at 
dulwich/_pack.c:55
Function `_PyString_Join' implicitly converted to pointer at dulwich/_pack.c:60
Function `PyString_AS_STRING' implicitly converted to pointer at 
dulwich/_pack.c:99
Function `PyString_FromStringAndSize' implicitly converted to pointer at 
dulwich/_pack.c:115

Function `PyString_AsString' implicitly converted to pointer at 
dulwich/_pack.c:122
Function `PyInt_FromLong' implicitly converted to pointer at dulwich/_pack.c:229
Function `Py_InitModule3' implicitly converted to pointer at dulwich/_pack.c:255
Function `PyString_FromStringAndSize' implicitly converted to pointer at 
dulwich/_diff_tree.c:284
Function `PyInt_FromLong' implicitly converted to pointer at 
dulwich/_diff_tree.c:290

Function `Py_InitModule' implicitly converted to pointer at 
dulwich/_diff_tree.c:398

however the same is true for the Debian builds.

Bug#800941: regression in 2.46: can't restore a just-trashed file

[Vlad Orlov]

Source: glib2.0
Version: 2.46.0-2
Severity: critical
Justification: breaks functionality of many file managers

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=749314
Control: tags -1 stretch sid upstream
Control: affects -1 caja nemo nautilus thunar


Steps to reproduce:
1. Move some file to trash using a file manager or gvfs-trash tool.
   Tested with the following file managers: Caja, Nemo, Nautilus, Thunar.
2. Browse trash and try to restore the file.

The file manager complains that it can't determine the original location
of the file, and so doesn't restore it. This is a regression in 2.46 since
restoring worked fine in 2.44.

The problem is that "trash::orig-path" and "trash::deletion-date" attributes
are not added to the trashed file. Without that the file manager can't
determine the original location of the file, and hence can't restore it.

You can check the file attributes by printing the moved file's info:
gvfs-info trash:///file_name

Check the upstream report [1] for more details.


[1] https://bugzilla.gnome.org/show_bug.cgi?id=749314

Bug#800932: ITP: andi -- Efficient Estimation of Evolutionary Distances

[Fabian Klötzl]

On 05.10.2015 10:55, Andreas Tille wrote:
> I guess for non-German speakers andy might be a random 4 letter 
> combination and nobody will confuse it with the tyical nickname of 
> a German Andreas. :-)

Great, I'll stick with "andi" then and continue packaging.

Thanks for the quick advice
Fabian

Bug#779593: geeqie: Color profile goes off then using full screen mode

[Magnus Berg]

Package: geeqie
Version: 1:1.2.2-1
Followup-For: Bug #779593

Hi again.

The problem still remain in Geeqie 1.2.2-1. And it remains in three different
computers with (if it can have some impact) free different graphic
cards/drivers (ATM Radeon (proprietary), Intel (in kernel) and Nvidia (in
kernel). All three run the latest XFCE4 and Debian Sid. All three are x64.

I have tree different monitor color profiles for the three monitors. But they
are all made with Argyll and are XYZLUT+MTX profiles. (Look-up-tables profile
with a Matrix-profile as backup.)

And I have tested different pictures, with different imbedded color profiles.
(My own pictures and pictures from color mamagement sites on the net.)

And the problem remain.
The color management works great in general but then I switch to full screen
mode Geeqie switch off color management. But you don't see what switch of in
the color management settings in the menu but your see it on the picture and on
the color management on/off-button in the bottom right corner.



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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.2.2-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo21.14.2-2
ii  libexiv2-14  0.25-2
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6-2
ii  libgcc1  1:5.2.1-21
ii  libgdk-pixbuf2.0-0   2.32.0-1
ii  libglib2.0-0 2.46.0-2
ii  libgtk2.0-0  2.24.28-1
ii  libjpeg62-turbo  1:1.4.1-2
ii  liblcms2-2   2.6-3+b3
ii  liblircclient0   0.9.0~pre1-1.2
ii  liblua5.1-0  5.1.5-8
ii  libpango-1.0-0   1.38.0-3
ii  libpangocairo-1.0-0  1.38.0-3
ii  libpangoft2-1.0-01.38.0-3
ii  libstdc++6   5.2.1-21
ii  libtiff5 4.0.5-1

Versions of packages geeqie recommends:
ii  exiftran 2.10-2
ii  exiv20.25-2
ii  imagemagick  8:6.8.9.9-6
ii  librsvg2-common  2.40.10-1
ii  lpr  1:2008.05.17.1
pn  ufraw-batch  
pn  zenity   

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.8.14-1+b1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.4.1-2
pn  ufraw
pn  xpaint   

-- no debconf information

Bug#800776: [Debian-ha-maintainers] Bug#800776: cluster-glue: please make the build reproducible

[Christoph Berg]

Re: Reiner Herrmann 2015-10-05 <20151005091641.gb22...@reiner-h.de>
> SOURCE_DATE_EPOCH is currently set by debhelper (dh) in our reproducible
> repository (and yesterday those changes were also uploaded to unstable).

Yay!

> We have currently no changes to export SOURCE_DATE_EPOCH for non-dh
> packages. So this one-line change would still be needed to get a
> reproducible package.

Oh sorry, I thought this bug was about a different package so I
assumed the packaging was dh. *blush*

We are currently reworking all of the HA stack packages and
cluster-glue hasn't been touched yet. There's chances cluster-glue
will be dropped completely, or at least reduced to much less content.

I'll make sure to keep an eye on reproducibility!

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/

Bug#761909: (no subject)

[Martin Pitt]

Benedict Broy [2014-11-23 23:45 +0100]:
> Hi, I have exactly the same problem. In my case, network-manager is
> responsible for shutting down the network connection.

Please let's keep this bug about interfaces configured with ifupdown.
NM is an entirely different mechanism, and unlike ifupdown systemd
isn't directly involved in that.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Bug#800776: [Debian-ha-maintainers] Bug#800776: cluster-glue: please make the build reproducible

[Reiner Herrmann]

Hi Christoph,

On Mon, Oct 05, 2015 at 09:56:00AM +0200, Christoph Berg wrote:
> Re: Reiner Herrmann 2015-10-03 <560fdee9.2090...@reiner-h.de>
> > +export SOURCE_DATE_EPOCH = $(shell date -d "$$(dpkg-parsechangelog 
> > -SDate)" +%s)
> 
> However, shouldn't this be set from the toolchain? Builds are only
> reproducible in practise now using a patched toolchain, and from what
> I got the plan is to make the toolchain set this variable, so I'd
> really expect the current reproducible.debian.net toolchain to expose
> this variable as well, even if it's not clear which bit (dpkg,
> debhelper, makefile include snippet ...) will set it in future.

SOURCE_DATE_EPOCH is currently set by debhelper (dh) in our reproducible
repository (and yesterday those changes were also uploaded to unstable).
We have currently no changes to export SOURCE_DATE_EPOCH for non-dh
packages. So this one-line change would still be needed to get a
reproducible package.

I don't think it was already discussed if SOURCE_DATE_EPOCH should
be exported also by other parts of the toolchain (like dpkg), so
I'm CC'ing the list.

Regards,
 Reiner



signature.asc
Description: Digital signature

Bug#761909: systemd does not unmount nfs shares before bringing down the network interface

[Martin Pitt]

Hello,

Giuseppe Bilotta [2014-09-16 20:15 +0200]:
> My fstab includes the line
> 
> labrador:/oneforall /oneforallnfs auto,exec   0   0
> 
> and the nfs share is automatically mounted when a network interface that
> can resolve `labrador` is brought up. I don't use NM nor wicd, so I
> bring the network interfaces up myself, typically with something like:
> 
> sudo ifup wlan0=home
> 
> However, when the network is brought down (manually, or automatically
> during system shutdown), the mountpoint is not unmounted, causing a
> number of issues.

This sounds very similar to https://launchpad.net/bugs/1492546 .
ifupdown's /etc/init.d/networking (and also /etc/init/networking.conf)
call functions check_network_file_systems() and check_network_swap()
and don't tear down the interface(s) in the above situation. This also
applies to e. g. iscsi.

But we don't do the same with the autogenerated ifup@.service -- that
always unconditionally calls "ifdown" on stopping. IMHO we should make
"systemctl stop ifup@ethX.service" a no-op at least during shutdown,
as stopping /etc/init.d/networking will stop them all anyway (or not,
if network file systems are being used).

We could change the ExecStop= to something like

  /bin/sh -ec '[ "$(systemctl is-system-running)" = stopping ] || /sbin/ifdown 
%I"

Or we just declare that we don't support manual stops, and you are
supposed to run "sudo ifdown ethX" to stop an interface. This is also
reasonable as we consider ifup@.service more like an internal helper
unit, not an user-visible/actionable one.

For sure I don't want to replicate the entire
check_network_file_systems()/check_network_swap() logic in
ifup@.service -- running this once on shutdown is bad enough :-)

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Bug#800668: iep ftbfs, missing build dependencies, still fails tests

[Matthias Klose]

[please reply to the submitter and/or the original sender of the email too]

> I can make a new upload with an explicit empty test target, will it
> solve your issue?

well, it certainly will succeed the build, however why not find out why it 
fails?

Bug#800939: ITP: python-openstackdocstheme -- extension support for Sphinx OpenStack doc

[Geert Stappers]

Control: retitle -1 ITP: python-openstackdocstheme -- extension support for 
Sphinx OpenStack doc

On Mon, Oct 05, 2015 at 10:58:17AM +0200, Thomas Goirand wrote:
} ITP
> * Package name: python-openstackdocstheme
> * URL : https://github.com/openstack/openstackdocstheme
>   Description : extension support for Sphin OpenStack doc

There is another  s/Sphin/Sphinx/ is needed


Thank you for your work on OpenStack

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#732723: cegui-mk2: Please upgrade OGRE dependency to 1.9 when upstream ready

[Muammar El Khatib]

On Sun, Sep 27, 2015 at 8:42 PM, Tobias Frost  wrote:
>> Yes. Go ahead. Today I contacted FTP masters because I think the
>> debian/copyright file is ok. I will keep you posted about it.
>>
>
> Recreated the repository in the meantime.


So far I haven't gotten a reply from FTP masters. The claimed the following:

> I found lots of files that are not mentioned in your debian/copyright:
>  doc/doxygen/falagard/fal_main.dox is GFDL
>  promo/* is CC-BY-SA
>  cegui/src/ScriptModules/Python/bindings/generate.py is GPL3
>  cegui/src/ScriptModules/Python/bindings/generators/__init__.py is GPL3
>  cegui/src/ScriptModules/Python/bindings/output/CEGUIOgreRenderer/* is BOOST
>  some fonts in datafiles/font/* have licenses as shown in 
> datafiles/fonts/Legal.txt

But those files were indeed included in the copyright file. See:

https://web.archive.org/web/20150907175032/https://ftp-master.debian.org/new/cegui-mk2_0.8.4-2.html

Regards,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#799346: rsyslog upgrade fails with message "start request repeated too quickly, refusing to start."

[Eric Van Buggenhaut]

I’m experiencing the same issue here:

root@kona:/home/eric# apt-get -f install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up rsyslog (8.4.2-1+deb8u1) ...
Job for rsyslog.service failed. See 'systemctl status rsyslog.service' and 
'journalctl -xn' for details.
invoke-rc.d: initscript rsyslog, action "restart" failed.
dpkg: error processing package rsyslog (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 rsyslog
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@kona:/home/eric#

root@kona:/home/eric# systemctl status rsyslog.service syslog.socket
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled)
   Active: failed (Result: start-limit) since Mon 2015-10-05 11:33:29 CEST; 50s 
ago
 Docs: man:rsyslogd(8)
   http://www.rsyslog.com/doc/
  Process: 11021 ExecStart=/usr/sbin/rsyslogd -n (code=exited, status=1/FAILURE)
 Main PID: 11021 (code=exited, status=1/FAILURE)

Oct 05 11:33:29 kona systemd[1]: Failed to start System Logging Service.
Oct 05 11:33:29 kona systemd[1]: Unit rsyslog.service entered failed state.
Oct 05 11:33:29 kona systemd[1]: rsyslog.service start request repeated too...t.
Oct 05 11:33:29 kona systemd[1]: Failed to start System Logging Service.
Oct 05 11:33:29 kona systemd[1]: Unit rsyslog.service entered failed state.
Oct 05 11:33:29 kona systemd[1]: rsyslog.service start request repeated too...t.
Oct 05 11:33:29 kona systemd[1]: Failed to start System Logging Service.

● syslog.socket - Syslog Socket
   Loaded: loaded (/lib/systemd/system/syslog.socket; static)
   Active: failed (Result: service-failed-permanent) since Mon 2015-10-05 
11:33:29 CEST; 50s ago
 Docs: man:systemd.special(7)
   http://www.freedesktop.org/wiki/Software/systemd/syslog
   Listen: /run/systemd/journal/syslog (Datagram)

Oct 05 11:33:29 kona systemd[1]: Unit syslog.socket entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

root@kona:/home/eric# journalctl -alb -u rsyslog.service
-- Logs begin at Tue 2015-09-29 13:24:13 CEST, end at Mon 2015-10-05 11:33:29 CE
Sep 29 13:24:23 kona systemd[1]: rsyslog.service: main process exited, code=exit
Sep 29 13:24:23 kona systemd[1]: Failed to start System Logging Service.
Sep 29 13:24:23 kona systemd[1]: Unit rsyslog.service entered failed state.
Sep 29 13:24:26 kona systemd[1]: rsyslog.service: main process exited, code=exit
Sep 29 13:24:26 kona systemd[1]: Failed to start System Logging Service.
Sep 29 13:24:26 kona systemd[1]: Unit rsyslog.service entered failed state.
Sep 29 13:24:28 kona systemd[1]: rsyslog.service: main process exited, code=exit
Sep 29 13:24:28 kona systemd[1]: Failed to start System Logging Service.
Sep 29 13:24:28 kona systemd[1]: Unit rsyslog.service entered failed state.
Sep 29 13:24:31 kona systemd[1]: rsyslog.service: main process exited, code=exit
Sep 29 13:24:31 kona systemd[1]: Failed to start System Logging Service.
Sep 29 13:24:31 kona systemd[1]: Unit rsyslog.service entered failed state.
Sep 29 13:24:32 kona systemd[1]: rsyslog.service: main process exited, code=exit
Sep 29 13:24:32 kona systemd[1]: Failed to start System Logging Service.
Sep 29 13:24:32 kona systemd[1]: Unit rsyslog.service entered failed state.
…


If you want me te perform additional checks, feel free to ask.

Bug#790847: Fwd: Emoji in lynx

[Thomas Dickey]

On Thu, Jul 02, 2015 at 07:53:15PM -0400, Thomas Dickey wrote:
> On Thu, Jul 02, 2015 at 12:55:15PM +0200, Sascha Brawer wrote:
> > Package: lynx
> > Version 2.8.9dev1-2
> > 
> > [I hope you don't mind that I'm reporting this to Debian via an HTML
> > e-mail, but it's kind of difficult to show the problem without pictures.
> > Also, apologies for having told lynx-dev already; next time I'll follow the
> > rules. -- Sascha]
> > 
> > Is it a known problem that lynx doesn't display Emoji?
> 
> not offhand -- it sounds as if someplace there is a 16-bit assumption.
> I'll have to investigate to pinpoint the problem.

Interestingly, the lynx package in Fedora22 works
(passably with vte
 -- none of the other terminals display Emoji
 -- no need for a list).

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#800942: new upstream (1.09)

[Daniel Baumann]

Package: plink

Hi,

it would be nice if you could upgrade to the current stable release (1.09).

Regards,
Daniel

Bug#800625: kdenlive: Segmentation fault on using "Affine" transition effect

[Patrick Matthäi]

Am 02.10.2015 um 23:21 schrieb Asumu Takikawa:

On 2015-10-01 14:01:59 -0400, Asumu Takikawa wrote:

Using the "Affine" transition effect in kdenlive causes a segfault.

After experimenting a bit, an error message that came up suggested that this was
happening because QtQuick couldn't be found.

Installing the qml-module-qtquick2 package made this segfault go away, so maybe
this should be a required dependency of kdenlive.

Cheers,
Asumu
Thanks for your investigation. Does this also resolves your bug #800623 
=> "Segmentation fault on use of "corners" effect" ?


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/