Bug#820744: xfdesktop4: Ctrl + Arrow keys should simply move to another icon and _not_ select it

[Rpnpif]

Package: xfdesktop4
Version: 4.10.2-3
Followup-For: Bug #820744

This bug is also existing in Jessie.
The Ctrl key works as the shift key.
This bug is annoying.

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

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

Versions of packages xfdesktop4 depends on:
ii  exo-utils   0.10.2-4
ii  libc6   2.19-18+deb8u3
ii  libcairo2   1.14.0-2.1
ii  libdbus-1-3 1.8.20-0+deb8u1
ii  libdbus-glib-1-20.102-1
ii  libexo-1-0  0.10.2-4
ii  libgarcon-1-0   0.2.1-2
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libglib2.0-02.42.1-1
ii  libgtk2.0-0 2.24.25-3
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.36.8-3
ii  libthunarx-2-0  1.6.3-2
ii  libwnck22   2.30.7-2
ii  libx11-62:1.6.2-3
ii  libxfce4ui-1-0  4.10.0-6
ii  libxfce4util6   4.10.1-2
ii  libxfconf-0-2   4.10.0-3
ii  xfdesktop4-data 4.10.2-3

Versions of packages xfdesktop4 recommends:
ii  dbus-x11 1.8.20-0+deb8u1
ii  librsvg2-common  2.40.5-1
ii  xdg-user-dirs0.15-2

Versions of packages xfdesktop4 suggests:
ii  menu  2.1.47

-- no debconf information

Bug#820854: ITP: fsm-lite -- frequency-based string mining (lite)

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: fsm-lite
  Version : 1.0
  Upstream Author : Niko Välimäki
* URL : https://github.com/nvalimak/fsm-lite
* License : GPL
  Programming Lang: C
  Description : frequency-based string mining (lite)
 A singe-core implementation of frequency-based substring mining used in
 bioinformatics to extract substrings that discriminate two (or more)
 datasets inside high-throughput sequencing data.


Remark: This package will be maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/fsm-lite.git

Bug#820813: apt-cacher-ng: add support for deb.debian.org

[Julien Cristau]

Control: found -1 0.8.0-3

On Tue, Apr 12, 2016 at 21:45:32 +0200, Eduard Bloch wrote:

> Control: tags 820813 + pending
> 
> Hallo,
> * Julien Cristau [Tue, Apr 12 2016, 06:32:16PM]:
> > Package: apt-cacher-ng
> > Version: 0.7.26-1
> 
> Just wondering, where is this version exactly from? It's not on 
> https://packages.qa.debian.org/a/apt-cacher-ng.html
> 
Oops.  It's what 'debcheckout apt-cacher-ng' gave me.  The repo is
configured to default to the 'master' branch, which is out of date, and
I failed to notice that yesterday.  You might want to point HEAD to a
more relevant branch :)

> > deb.debian.org is an experimental service using a CDN to serve the
> > debian archive.  It would be nice if apt-cacher-ng recognized it as a
> > debian mirror.
> 
> Ok, but I would add in similar form to sid and push a stable backport
> RSN.
> 
Thanks.

Cheers,
Julien
-- 
Julien Cristau  
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

Bug#820855: crashes when compiled with -D_GLIBCXX_DEBUG

[Erik Thiele]

Package: libsigc++-2.0-0c2a
Version: 2.2.10-0.2

erik@host:~/sigcpp_bug$ cat bug.cpp
#include 
#include 

using namespace std;
using namespace sigc;

class sigtester : public sigc::trackable {
public:
  sigtester();
  void myslot();
  signal0 mysig;
};

sigtester::sigtester()
{ cout << "sigtester::sigtester\n"; }

void sigtester::myslot()
{ cout << "sigtester::myslot\n"; }

void globalSlot()
{ cout << "globalSlot\n"; }

int main(int, char *[])
{
  sigtester st;
  cout << "first test starts\n";
  st.mysig.connect(sigc::mem_fun(&st, &sigtester::myslot));
  cout << "first test passed\n";

  signal0 thesig;
  cout << "second test starts\n";
  thesig.connect(sigc::ptr_fun(&globalSlot));
  cout << "second test passed\n";

  return 0;
}

erik@host:~/sigcpp_bug$: g++ -g -Wall -Werror -D_GLIBCXX_DEBUG \
  $(pkg-config --cflags sigc++-2.0) \
  $(pkg-config --libs sigc++-2.0) bug.cpp -o will_crash

erik@host:~/sigcpp_bug$ g++ -g -Wall -Werror \
  $(pkg-config --cflags sigc++-2.0) \
  $(pkg-config --libs sigc++-2.0) bug.cpp -o will_work

erik@host:~/sigcpp_bug$ ./will_work 
sigtester::sigtester
first test starts
first test passed
second test starts
second test passed
erik@host:~/sigcpp_bug$ ./will_crash 
sigtester::sigtester
first test starts
Segmentation fault

erik@host:~/sigcpp_bug$ gdb ./will_crash 
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 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 "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/global/erik/sigcpp_bug/will_crash...done.
(gdb) run
Starting program: /home/global/erik/sigcpp_bug/will_crash 
sigtester::sigtester
first test starts

Program received signal SIGSEGV, Segmentation fault.
0xb7f723bd in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0xb7f723bd in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#1  0xb7f7246a in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#2  0xb7f7267c in __gnu_debug::_Safe_iterator_base::_M_detach() ()
from /usr/lib/i386-linux-gnu/libstdc++.so.6 #3  0x0804937b in
__gnu_debug::_Safe_iterator_base::~_Safe_iterator_base
(this=0xb66c, __in_chrg=)
at /usr/include/c++/4.7/debug/safe_base.h:105 #4  0x08049489 in
__gnu_debug::_Safe_iterator,
std::__debug::list >
>::~_Safe_iterator (this=0xb66c, __in_chrg=)
>at /usr/include/c++/4.7/debug/safe_iterator.h:118 #5  0x080496d6 in
>sigc::signal0::connect (this=0xb6ac, slot_=...)
>at /usr/include/sigc++-2.0/sigc++/signal.h:2661 #6  0x08049091 in main
>() at bug.cpp:33 (gdb) 

this bug can also be reproduced on package version 2.4.0-1 on debian
jessie.

The problem is, that because of the bug I cannot use _GLIBCXX_DEBUG for
a large project where even only a small part of it uses libsigc++.

Also I am not sure if the problem is libsigc++ or the debugging feature
of libc.


cya
erik

Bug#820856: bash: Please add ~/.local/bin to the default $PATH

[Nathaniel Smith]

Package: bash
Version: 4.3-14+b1
Severity: normal

~/.local/bin is a de-facto standard place to put per-user executables -- for
example, Fedora automatically places it on the $PATH, and PEP 370 makes it the
standard place for unprivileged installs of Python packages to put their
scripts (and therefore, this is where 'pip install --user ...' puts scripts).

Unfortunately, Debian's does *not* add this directory to $PATH by default,
which means that 'pip install --user' doesn't work.

Indeed, Debian doesn't add any per-user directories to $PATH unconditionally --
all it does is add ~/bin if ~/bin exists. So even if pip started dropping
binaries into ~/bin, you'd still have the awful new user experience of having
to restart your shell after running 'pip install --user' for the first time.
Plus, I think everyone would agree that it would be Rude for pip to
automatically create a visible directory in $HOME. ~/.local/bin is a much
better place for automated tools like this. So this seems like something that
Debian has to fix in /etc/skel, not something that pip can fix on its own.
(Unless pip starts editing individual user's ~/.profile files, I guess.)

In addition, the fact that ~/.local/bin is missing from the Debian/Ubuntu
default $PATH means that the obvious 'pip install --user ' approach
does not work for lots of users; this is one reason that upstream documentation
tends to recommend 'sudo pip install ' -- unlike --user, it actually
works. I think we all agree that 'sudo pip' is an abomination, and we want
upstream documentation to stop recommending it; adding ~/.local/bin to $PATH
makes it much easier to get upstream on board with this and kill 'sudo pip'.

Therefore, I suggest that ~/.local/bin should be added to the default $PATH on
Debian.

There are a few minor details about how to do this. One question is whether it
should be added at the end or the beginning of $PATH. Fedora adds it at the end
-- specifically, their /etc/skel/.bash_profile has the line:

  PATH=$PATH:$HOME/.local/bin:$HOME/bin

But IMO this is unfortunate, because if I just installed a binary locally for
myself, then often that's because I found that the system version is too old or
something -- I want the thing I just installed to be the thing that's found,
overriding the system version. Really though either way would be much better
than the current situation.

The other question is where it should be added. The two obvious options are
/etc/skel/.profile, and /etc/profile. Again, Fedora uses
/etc/skel/.bash_profile, so I guess adding it to Debian's /etc/skel/.profile
would make sense. (Debian has no /etc/skel/.bash_profile; Fedora has no
/etc/skel/.profile; so I treat them as equivalent.) The advantage of adding it
to /etc/profile would be that it would be added to existing installs, whereas
adding it to /etc/skel/.profile would only affect newly created accounts (and
thus take much longer to propagate out to the point where pip and friends start
actually working). But again, either option would be much better than the
current situation.



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

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

Versions of packages bash depends on:
ii  base-files   9.6
ii  dash 0.5.8-2.2
ii  debianutils  4.7
ii  libc62.22-5
ii  libncurses5  6.0+20160319-1
ii  libtinfo56.0+20160319-1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.2

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Jan Henke]

Package: java-package
Version: 0.60
Severity: normal

Given the following situation. I have openjdk-8-jdk installed from the
archive. For work I need the Oracle JDK, so I download the *.tar.gz and
create a debian package from it with java-package. I install the created
package, so I have both the openjdk-8-jdk from the archive and the
Oracle JDK installed.

Now I run java -version on the command line.

Expected result: The java binary from the Oracle JDK is used by default.
Actual result: The openjdk java binary is still used.
(It is the same for all binaries, which are provided by both Java
implementations).

It turns out, the package generated by java-package has a much lower
priority(380) for update-alternatives then then openjdk(~1000) package.

Please change the java-package tool, so that the generated packages have
the highest priority of all Java implemenations and are used by default.

Rationale: If I create a Debian package with make-jpkg and install it,
it is a deliberate act, that I want that Java implemantation on my
machine. It should therefore be used by default. Not using this
implementation after installing it is unexpected and against user expectation.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages java-package depends on:
ii  build-essential  12.1ubuntu2
ii  debhelper9.20160115ubuntu3
ii  dpkg-dev 1.18.4ubuntu1
ii  fakeroot 1.20.2-1ubuntu1
ii  libasound2   1.1.0-0ubuntu1
ii  libfontconfig1   2.11.94-0ubuntu1
ii  libgl1-mesa-glx  11.2.0-1ubuntu1
ii  libgtk2.0-0  2.24.30-1ubuntu1
ii  libx11-6 2:1.6.3-1ubuntu2
ii  libxslt1.1   1.1.28-2.1
ii  libxtst6 2:1.2.2-1
ii  libxxf86vm1  1:1.1.4-1
ii  unzip6.0-20ubuntu1

java-package recommends no packages.

Versions of packages java-package suggests:
pn  openjdk-7-jre  

-- no debconf information

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

[Tobias Frost]

Package: vice
Followup-For: Bug #725629

I'm currently rebuilding vice in a loop on fischer.debian.org with both patches 
applied and it looks quite good so far.

As I'd like to push things (especially the libpng1.6 transition) forward, I 
will NMU if successful.

Dear maintainers, 
Please let me know if it would be in order to LowNMU?

-- 
tobi

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

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

Bug#725848:

[Nathaniel Smith]

On Fedora, there's a line in /etc/skel/.bash_profile that adds
~/.local/bin to the default PATH. Debian doesn't have an equivalent.

I just filed #820856 to hopefully get this added to Debian.

(It's possible that in the mean time pip might need to grow some logic
to check whether the user's PATH is correct, and even offer to fix it
up by appending something to the user's ~/.something. This is a pretty
significant stumbling block for new users, and even if Debian fixes
this today then it will take quite some time for the change to
propagate out... esp. if the fix goes into /etc/skel, because in that
case existing installations will *never* get the fix, only new ones
will.)

-- 
Nathaniel J. Smith -- https://vorpus.org

Bug#820858: override: screen:misc/standard

[Axel Beckert]

Package: ftp.debian.org
Severity: normal

Hi,

a while ago, it was requested that the "screen" package becomes
"Priority: standard".

Reasoning of the original request:

> screen is small and commonly required on a wide variety of systems
> where only the standard system utilities (and openssh-server) are
> installed, yet it needs to be installed separately each time. (Most
> frustrating with newly installed virtual machines around the time of
> a release when new images need testing.)

Please see https://bugs.debian.org/783524 for the original change
request.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Bug#819016: jellyfish: Rename python bindings module name

[Diego M. Rodriguez]

Hello Andreas,

I dropped by #debian-python yesterday in order to clarify conformance
to Python Policy 3.3 as suggested during a review on the ITP [1], and
the conversation derived into a suggestion about revisiting the decision
we made about the package names (excerpt from the log [2]):

Apr 12 17:56:45  there are 2 reported installations of python3-jellyfish 
on popcon - I'd rename the other python3-jellyfish now (module and binary 
package) and a then upload yours with python3-jellyfish name

I'm wondering if you could share your thoughts on this issue and if you
would be open to this change, even if it is quite a deviation from our
envisaged solution? I'd be happy to move the discussion to other
channels if needed, and again, thanks a lot for your patience on this
issue.

Best regards,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432#85
[2] http://paste.debian.net/432489
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Markus Koschany]

Am 13.04.2016 um 09:39 schrieb Jan Henke:
> Package: java-package
> Version: 0.60
> Severity: normal
> 
> Given the following situation. I have openjdk-8-jdk installed from the
> archive. For work I need the Oracle JDK, so I download the *.tar.gz and
> create a debian package from it with java-package. I install the created
> package, so I have both the openjdk-8-jdk from the archive and the
> Oracle JDK installed.
> 
> Now I run java -version on the command line.
> 
> Expected result: The java binary from the Oracle JDK is used by default.
> Actual result: The openjdk java binary is still used.
> (It is the same for all binaries, which are provided by both Java
> implementations).
> 
> It turns out, the package generated by java-package has a much lower
> priority(380) for update-alternatives then then openjdk(~1000) package.
> 
> Please change the java-package tool, so that the generated packages have
> the highest priority of all Java implemenations and are used by default.
> 
> Rationale: If I create a Debian package with make-jpkg and install it,
> it is a deliberate act, that I want that Java implemantation on my
> machine. It should therefore be used by default. Not using this
> implementation after installing it is unexpected and against user expectation.

I disagree with this rationale because making non-free software the
default should always be a deliberate action. If two alternatives exist,
OpenJDK 8 and Oracle JDK, then the free alternative should be promoted
and always have the highest priority. I would expect that people who
install the Oracle JDK would use the update-alternative mechanism
manually the same way they would switch between two versions of OpenJDK.

I don't think we should change the current behavior and mark this bug as
wontfix because there will always be people who will argue for or
against this proposal.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#650601: libpng1.6 transition

[Emilio Pozuelo Monfort]

Control: tags -1 = confirmed pending

libpng1.6 is now in testing. Marking this as pending until we can remove
src:libpng from testing.

Cheers,
Emilio

Bug#820792: irssi-plugin-xmpp package is of very poor quality

[Vitaliyi]

Yes, it do not segfault with newer version and it seems finds libraries.


On Tue, Apr 12, 2016 at 9:35 PM, Florian Schlichting 
wrote:

> Hi Vitaliyi,
>
> On Tue, Apr 12, 2016 at 12:42:03PM +0100, Vitaliyi wrote:
> > Package: irssi-plugin-xmpp
> > Version: 0.53-1
> >
> > When you try to use it the first time, you receive the following message
> >
> > 14:25 -!- Irssi: Error loading module xmpp/core:
> >   /usr/lib/irssi/modules/libxmpp_core.so: ... No such file or
> > directory
>
> exactly what version of irssi and irssi-plugin-xmpp are you using? On
> what architecture? Please use 'reportbug' to report bugs, so this
> important information gets included automatically.
>
> Your error message sounds like you're using an old version of irssi
> (before 0.8.19) with a current version of an irssi plugin. However,
> irssi plugins need to be compiled against the irssi version they are
> used with, else breakage may occur. irssi versions from 0.8.19 check for
> that when loading a module (and they also look for modules in the
> multiarch path), and will complain if ABI versions don't match.
>
> > I've created symlinks in that path and then tried to connect to habber
> > server with -ssl flag.
> > While I read manual trying to find how to register on XMPP server, irssi
> > segfaulted.
>
> Likely a consequence of ABI mismatch between irssi and irssi-plugin-xmpp
>
> Please make sure you're using irssi 0.8.19-1
>
> Florian
>
>

Bug#820859: libuv1: Temporarily block testing migration, phase-locking it to nodejs LTS

[Luca Bruno]

Package: libuv1
Version: 1.9.0-1
Severity: normal

We still need to clear up whether nodejs LTS are locked to spcific libuv1 
minor versions or not.
For the moment, we block 1.9.0 here and wait for clarification before letting
it in testing.
Discussion is up at 
https://lists.debian.org/debian-release/2016/04/msg00280.html

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Emmanuel Bourg]

Le 13/04/2016 10:04, Markus Koschany a écrit :

> I don't think we should change the current behavior and mark this bug as
> wontfix because there will always be people who will argue for or
> against this proposal.

We could also add a parameter to change the priority when the package is
generated. That would satisfy both views.

Emmanuel Bourg

Bug#820804: gitlab: install fails with Could not find gem 'gitlab_git (~> 7.2.22)'

[Olivier Berger]

On Tue, Apr 12, 2016 at 04:41:24PM +0200, Olivier Berger wrote:
> 
> I've tried to install gitlab on a fresh testing/stretch empty VM, and got :
> 
> Setting up gitlab (8.4.3+dfsg-12) ...
> Creating/updating gitlab user account...
> adduser: The user `gitlab' already exists.
> Proceeding with existing gitlab user...
> GITLAB_HOST=localhost
> Create database if not present
> Make gitlab user owner of gitlab_production database...
> ALTER DATABASE
> Grant all privileges to gitlab user...
> GRANT
> Verifying we have all required libraries...
> Could not find gem 'gitlab_git (~> 7.2.22)' in any of the gem sources listed 
> in
> your Gemfile or available on this machine.
> dpkg: error processing package gitlab (--configure):
>  subprocess installed post-installation script returned error exit status 7
> Errors were encountered while processing:
>  gitlab
> 

A problem also lies in the gitlab_emoji, btw.

It seems a workaround is to fix the dependencies stated in 
/usr/share/gitlab/Gemfile :
--- Gemfile.orig2016-04-12 16:44:37.848613241 +0200
+++ Gemfile 2016-04-13 10:16:20.919850006 +0200
@@ -50,7 +50,7 @@
 
 # Extracting information from a git repository
 # Provide access to Gitlab::Git library
-gem "gitlab_git", '~> 7.2.22'
+gem "gitlab_git", '~> 8.2.0'
 
 # LDAP Auth
 # GitLab fork with several improvements to original library. For full list of 
changes
@@ -201,7 +201,7 @@
 gem 'addressable','~> 2.3.8'
 gem 'bootstrap-sass', '~> 3.3.0'
 gem 'font-awesome-rails', '~> 4.2'
-gem 'gitlab_emoji',   '~> 0.2.0'
+gem 'gitlab_emoji',   '~> 0.3.1'
 gem 'gon','~> 6.0.1'
 gem 'jquery-atwho-rails', '~> 1.3.2'
 gem 'jquery-rails',   '~> 4.0.0'

I checked the versions of ruby-gitlab-git and ruby-gitlab-emoji packages to 
find these. Hope this is sound.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

[GCS]

Hi Tobias,

On Wed, Apr 13, 2016 at 9:39 AM, Tobias Frost  wrote:
> Package: vice
> Followup-For: Bug #725629
>
> I'm currently rebuilding vice in a loop on fischer.debian.org with both 
> patches applied and it looks quite good so far.
>
> As I'd like to push things (especially the libpng1.6 transition) forward, I 
> will NMU if successful.
 If possible, please send a patch instead. I can do a normal upload fast.

Cheers,
Laszlo/GCS

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Jan Henke]

Hi,

I would prefer this. An extra option while creating the package to give it the 
highest priority.

Markus, while in principle I agree with you, sadly my job requires me to use 
the propritary JDK. I do think this use case should be as simple as possible 
and not made more difficult "because it is non free software".

Best Regards,
Jan Henke



Jan Henke | Softwareentwickler
Hugendubel Digital GmbH & Co. KG
Friesenweg 1 | D-22763 Hamburg
Telefon: +49 (0)40 851 94 - 109 | Telefax: +49 (0)40 851 94 - 113
E-Mail: jhe...@hugendubel-digital.de

www.hugendubel.de – Die Welt der Bücher
www.eBook.de – Meine Bücher immer dabei
_

Geschäftsführung: Per Dalheimer, Dr. Stefan Höllermann
Umsatzsteuer ID: DE300667265 | AG Hamburg HRA 118925
_

-Original Message-
From: Emmanuel Bourg [mailto:emmanuel.bo...@gmail.com] On Behalf Of Emmanuel 
Bourg
Sent: Wednesday, April 13, 2016 10:29 AM
To: 820...@bugs.debian.org; Jan Henke
Subject: Re: Bug#820857: java-package: Generated JDK package should have higher 
priority than existing openjdk packages

Le 13/04/2016 10:04, Markus Koschany a écrit :

> I don't think we should change the current behavior and mark this bug as
> wontfix because there will always be people who will argue for or
> against this proposal.

We could also add a parameter to change the priority when the package is
generated. That would satisfy both views.

Emmanuel Bourg

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Diego M. Rodriguez]

control: block -1 by 819016

Hello Giafranco,

> FWIW adding "u" to the strings indeed fixed the issue
> e.g. 'string' becomes u'string' (IIRC forcing unicode)

thanks, it's been confirmed by upstream and promptly fixed on the
upstream repository [1].

> BTW, the Python policy is something like
> "python-foo" means "import foo" works.
> Adding str migth deviate from the policy, you might want to ask #-python
> about this specific issue (and quote the conversation here)

thanks for letting me know about the potential Policy issue with the
package name. After discussing it at #debian-python [2], it seems that
the deviation would be acceptable, however it was suggested that the
conflicts as a whole would be better solved by renaming the *existing*
package:

 there are 2 reported installations of python3-jellyfish on popcon - I'd 
rename the other python3-jellyfish now (module and binary package) and a then 
upload yours with python3-jellyfish name

> thanks, I'll wait for your action,

I have commented on #819016 in the hopes of discussing the new approach
with the maintainer of the existing jellyfish package, and I'll ping
you back once the situation is sorted out.

Again, thanks a lot,

[1] https://github.com/jamesturk/jellyfish/issues/51
[2] http://paste.debian.net/432489
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#820792: Info received (Bug#820792: irssi-plugin-xmpp package is of very poor quality)

[Vitaliyi]

Also it writes a lot of the following messages to console

11:39 -!- Irssi: warning jabber.ipredator.se: no response from server


On Wed, Apr 13, 2016 at 9:21 AM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

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

Bug#820860: Apt sees versioned suggestions as recommends or soft depends

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: apt
Version: 1.2.10
Severity: normal

I found a strange problem that I only see with cvs -> mksh now.

I never installed mksh on my systems willfully. But I have cvs installed
on all such systems.

Now cvs comes with "Suggests: mksh (>= 40~), rcs" what makes mksh always
installed if I issue a "apt-get dist-upgrade". I had to file the
preferences below to mitigate that problem.

It seems that the versioned suggestion makes it a recommend or a "soft"
depend as it is easily possible to deinstall mksh afterwards, only to
have them installed again in the next dist-upgrade.

Ah, here is the preferences settings ad reportbug does not include that:
   Package: mksh:i386
   Pin: version *
   Pin-Priority: -1000

   Package: mksh
   Pin: version *
   Pin-Priority: -1000

- -- Package-specific info:

- -- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-headers-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.2\.8$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.2\.8$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.2\.8$";
APT::NeverAutoRemove:: "^gnumach-image-4\.2\.8$";
APT::NeverAutoRemove:: "^.*-modules-4\.2\.8$";
APT::NeverAutoRemove:: "^.*-kernel-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-tools-4\.2\.8$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "1";
APT::Periodic::MaxAge "30";
APT::Periodic::MinAge "2";
APT::Periodic::MaxSize "500";
APT::Update "";
APT::Update::Pre-Invoke "";
APT::Update::Pre-Invoke:: "if [ -x /usr/bin/daptup ]; then /usr/bin/daptup 
--hook --pre; fi";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "if [ -x /usr/bin/daptup ]; then /usr/bin/daptup 
--hook --post; fi";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "touch 
/var/lib/apt/periodic/update-success-stamp 2>/dev/null || true";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Get "";
APT::Get::Show-Upgraded "true";
APT::Get::Show-Versions "true";
APT::Get::Purge "true";
APT::Cache "";
APT::Cache::AllVersions "false";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg

Bug#820861: apt reportbug collection script does not include preferences in /etc/apt/preferences.d

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: apt
Version: 1.2.10
Severity: minor

When reporting bug in reportbug, all the preferences in
/etc/apt/preferences.d does not get included in the report. Only
/etc/apt/preferences itself gets included.

I did not check if that is also the case with apt.conf.d and
sources.list.d.

- -- Package-specific info:

- -- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-headers-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.2\.8$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.2\.8$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.2\.8$";
APT::NeverAutoRemove:: "^gnumach-image-4\.2\.8$";
APT::NeverAutoRemove:: "^.*-modules-4\.2\.8$";
APT::NeverAutoRemove:: "^.*-kernel-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.2\.8$";
APT::NeverAutoRemove:: "^linux-tools-4\.2\.8$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "1";
APT::Periodic::MaxAge "30";
APT::Periodic::MinAge "2";
APT::Periodic::MaxSize "500";
APT::Update "";
APT::Update::Pre-Invoke "";
APT::Update::Pre-Invoke:: "if [ -x /usr/bin/daptup ]; then /usr/bin/daptup 
--hook --pre; fi";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "if [ -x /usr/bin/daptup ]; then /usr/bin/daptup 
--hook --post; fi";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "touch 
/var/lib/apt/periodic/update-success-stamp 2>/dev/null || true";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Get "";
APT::Get::Show-Upgraded "true";
APT::Get::Show-Versions "true";
APT::Get::Purge "true";
APT::Cache "";
APT::Cache::AllVersions "false";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::B

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Markus Koschany]

Control: severity -1 wishlist

Am 13.04.2016 um 10:29 schrieb Emmanuel Bourg:
> Le 13/04/2016 10:04, Markus Koschany a écrit :
> 
>> I don't think we should change the current behavior and mark this bug as
>> wontfix because there will always be people who will argue for or
>> against this proposal.
> 
> We could also add a parameter to change the priority when the package is
> generated. That would satisfy both views.
> 
> Emmanuel Bourg

Sure. Good idea. Then this one is probably a wishlist bug.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#788798: [Pkg-utopia-maintainers] Bug#788798: avahi-daemon: MDNS sometimes doesn't work after boot until avahi-daemon is restarted

[Michel Dänzer]

On 16.06.2015 11:23, Michel Dänzer wrote:
> 
> BTW, this time it started working by itself (without restarting avahi
> daemon) after a few minutes. No idea what happened to make it work.
> I'll keep an eye on whether it always starts working by itself after a
> while.

That does seem to be the case, though sometimes it could take a long
time (on the order of an hour rather than just a minute).


FWIW, restarting avahi-daemon in a script in /etc/network/if-up.d/ seems
to prevent the problem from occurring.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature

Bug#795699: mcabber: Please package version 1.0.0

[Veres-Szentkiralyi Andras]

Dear Maintainers,
it's become much worse, since a new version of loudmouth has been
packaged by Debian that replaces MD5 fingerprints with SHA-256 ones, but
mcabber has not been packaged in the same way, so right now there's no
way to verify the authenticity of the certificate with a fingerprint in
the config files, as mcabber can't deal with the SHA-256 hash provided
by libloudmouth as it expects MD5.

Please, package mcabber 1.0.2 (released on 2016-02-27) or backport the
SHA-256 functionality, as I've been unable to use mcabber ever since.
-- 
Regards,
András Veres-Szentkirályi


pgpxMC0G2VM86.pgp
Description: PGP signature

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Markus Koschany]

Am 13.04.2016 um 10:32 schrieb Jan Henke:
> Hi,
> 
> I would prefer this. An extra option while creating the package to give it 
> the highest priority.
> 
> Markus, while in principle I agree with you, sadly my job requires me to use 
> the propritary JDK. I do think this use case should be as simple as possible 
> and not made more difficult "because it is non free software".
> 
> Best Regards,
> Jan Henke

I also have to use the proprietary JDK from time to time to test my
software. However I think Debian is about free software and everything
we do should reflect this and thus OpenJDK was made the default JDK/JRE.

I also don't see the difficulties in using

sudo update-alternatives --config java


after the installation of the Oracle JDK and to change the default to
the preferred one. That would have taken less time than to file this bug
report.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#820862: xen-hypervisor-4.4-amd64: Xen VM on Jessie freezes often with INFO: task jbd2/xvda2-8:111 blocked for more than 120 seconds

[Christoph Keller]

Package: xen-hypervisor-4.4-amd64
Version: 4.4.1-9+deb8u4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   Running Backup Exec or a copy command to NFS-Share causes the VM regurarly 
to freeze. First message on VM-Console:
   
---
[ 1680.060125] INFO: task jbd2/xvda2-8:111 blocked for more than 120 seconds.
[ 1680.060139] Not tainted 3.16.0-4-amd64 #1
[ 1680.060144] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1680.060150] jbd2/xvda2-8 D 88000408c768 0 111 2 0x
[ 1680.060159] 88000408c310 0246 00012f00 
8801f103ffd8
[ 1680.060167] 00012f00 88000408c310 8801fea937b0 
8801fefeea88
[ 1680.060175] 0002 8113d0e0 8801f103fbd0 
8801f103fc50
[ 1680.060183] Call Trace:
[ 1680.060196] [] ? wait_on_page_read+0x60/0x60
[ 1680.060204] [] ? io_schedule+0x99/0x120
[ 1680.060210] [] ? sleep_on_page+0xa/0x10
[ 1680.060216] [] ? __wait_on_bit+0x5c/0x90
[ 1680.060222] [] ? wait_on_page_bit+0x7f/0x90
[ 1680.060231] [] ? autoremove_wake_function+0x30/0x30
[ 1680.060246] [] ? pagevec_lookup_tag+0x1d/0x30
[ 1680.060254] [] ? filemap_fdatawait_range+0xd0/0x160
[ 1680.060260] [] ? submit_bio+0x71/0x150
[ 1680.060266] [] ? bio_alloc_bioset+0x198/0x290
[ 1680.060275] [] ? 
jbd2_journal_commit_transaction+0xa5c/0x1950 [jbd2]
[ 1680.060283] [] ? xen_end_context_switch+0xe/0x20
[ 1680.060292] [] ? finish_task_switch+0x46/0xf0
[ 1680.060297] [] ? _raw_spin_unlock_irqrestore+0x13/0x20
[ 1680.060304] [] ? kjournald2+0xb2/0x240 [jbd2]
[ 1680.060309] [] ? prepare_to_wait_event+0xf0/0xf0
[ 1680.060314] [] ? commit_timeout+0x10/0x10 [jbd2]
[ 1680.060321] [] ? kthread+0xbd/0xe0
[ 1680.060326] [] ? kthread_create_on_node+0x180/0x180
[ 1680.060332] [] ? ret_from_fork+0x58/0x90
[ 1680.060336] [] ? kthread_create_on_node+0x180/0x180
[ 1920.060121] INFO: task jbd2/xvda2-8:111 blocked for more than 120 seconds.
[ 1920.060133] Not tainted 3.16.0-4-amd64 #1
[ 1920.060138] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1920.060144] jbd2/xvda2-8 D 88000408c768 0 111 2 0x
[ 1920.060153] 88000408c310 0246 00012f00 
8801f103ffd8
[ 1920.060163] 00012f00 88000408c310 8801fea937b0 
8801fefeea88
[ 1920.060172] 0002 8113d0e0 8801f103fbd0 
8801f103fc50
[ 1920.060181] Call Trace:
[ 1920.060189] [] ? wait_on_page_read+0x60/0x60
[ 1920.060197] [] ? io_schedule+0x99/0x120
[ 1920.060203] [] ? sleep_on_page+0xa/0x10
[ 1920.060209] [] ? __wait_on_bit+0x5c/0x90
[ 1920.060216] [] ? wait_on_page_bit+0x7f/0x90
[ 1920.060223] [] ? autoremove_wake_function+0x30/0x30
[ 1920.060231] [] ? pagevec_lookup_tag+0x1d/0x30
[ 1920.060243] [] ? filemap_fdatawait_range+0xd0/0x160
[ 1920.060251] [] ? submit_bio+0x71/0x150
[ 1920.060262] [] ? bio_alloc_bioset+0x198/0x290
[ 1920.060269] [] ? 
jbd2_journal_commit_transaction+0xa5c/0x1950 [jbd2]
[ 1920.060275] [] ? xen_end_context_switch+0xe/0x20
[ 1920.060280] [] ? finish_task_switch+0x46/0xf0
[ 1920.060285] [] ? _raw_spin_unlock_irqrestore+0x13/0x20
[ 1920.060291] [] ? kjournald2+0xb2/0x240 [jbd2]
[ 1920.060296] [] ? prepare_to_wait_event+0xf0/0xf0
[ 1920.060303] [] ? commit_timeout+0x10/0x10 [jbd2]
[ 1920.060308] [] ? kthread+0xbd/0xe0
[ 1920.060312] [] ? kthread_create_on_node+0x180/0x180
[ 1920.060318] [] ? ret_from_fork+0x58/0x90
[ 1920.060322] [] ? kthread_create_on_node+0x180/0x180
[ 1920.060328] INFO: task rs:main Q:Reg:338 blocked for more than 120 seconds.
[ 1920.060332] Not tainted 3.16.0-4-amd64 #1 
-- -- or   
- 
INFO: task systemd-tmpfile:1304 blocked for more than 120 seconds.
[ 1080.060138] Not tainted 3.16.0-4-amd64 #1
[ 1080.060142] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1080.060149] systemd-tmpfile D 8801f3b4ee38 0 1304 1 0x
[ 1080.060158] 8801f3b4e9e0 0286 00012f00 
88000367bfd8
[ 1080.060166] 00012f00 8801f3b4e9e0 8801feb937b0 
8801ff009158
[ 1080.060174] 0002 811d7620 88000367bc70 
8800042933a8
[ 1080.060182] Call Trace:
[ 1080.060194] [] ? generic_block_bmap+0x50/0x50
[ 1080.060203] [] ? io_schedule+0x99/0x120
[ 1080.060209] [] ? sleep_on_buffer+0xa/0x10
[ 1080.060215] [] ? __wait_on_bit+0x5c/0x90
[ 1080.060223] [] ? generic_block_bmap+0x50/0x50
[ 1080.060227] [] ? out_of_line_wait_on_bit+0x77/0x90
[ 1080.060233] [] ? autoremove_wake_function+0x30/0x30
[ 1080.060246] [] ? ext4_bread+0x5b/0x90 [ext4]
[ 1080.060253] [] ? __ext4_read_dirblock+0x3a/0x3c0 [ext4]
[ 1080.060262] [] ? htree_dirblock_to_tree+0x40/0x190 [ext4]
[ 1080.060269] [] ? ext4_htree_fill_tree+0xc1/0x250 [ext4]
[ 1080.060274] [] ? path_openat+0x1

Bug#820864: engauge-digitizer: Build-Depends on old libpng12-dev

[Gianfranco Costamagna]

Source: engauge-digitizer
Version: 7.2-1
Severity: serious
Tags: patch

Hi, please stop depending on libpng12-dev, it is superceeded by libpng-dev now 
(pointing at libpng16-16).

thanks.

G.

Bug#820863: eztrace: funny configure errors: 'FC: command not found' etc.

[Andreas Beckmann]

Source: eztrace
Version: 1.1-2-1
Severity: minor

Something seems to be broken in configure, otherwise we wouldn't get
such output:

../configure: line 19747: FC: command not found
../configure: line 19748: FCFLAGS: command not found
../configure: line 20136: -lz: command not found
../configure: line 20388: -lz: command not found
../configure: line 20536: -lz: command not found
../configure: line 20564: -liberty: command not found

But this does not affect the success of the configure and build
processes.


Andreas

Bug#820666: [Pkg-php-pecl] Bug#820666: php5-redis: Segfault on pear upgrade-all with php5-redis installed

[Prunk-Éger Edgár]

I'm sorry, I'm not sure how to create the backtrace.

Edgar

--


On 2016-04-11 16:39, Ondřej Surý wrote:

Control: severity -1 normal
Control: tags -1 +moreinfo

Please install appropriate -dbg packages and provide workable backtrace
for the failing command.

Also please don't abuse bug severities. This is an important bug at
most, but most likely normal as it's not "a bug which has a major effect
on the usability of a package, without rendering it completely unusable
to everyone", so marking it as such.

Cheers,

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Thorsten Glaser]

On Wed, 13 Apr 2016, Jan Henke wrote:

> It turns out, the package generated by java-package has a much lower
> priority(380) for update-alternatives then then openjdk(~1000) package.
> 
> Please change the java-package tool, so that the generated packages have
> the highest priority of all Java implemenations and are used by default.

Eh, please no. This way you can have the generated package in
an internal repo, and people using it on the occasion, without
impeding the rest of the system.

Besides, the safest way is to have only one JRE installed anyway…

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#820865: diagnostics: FTBFS: stacktrace/bin/bash: not found

[Chris Lamb]

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

Dear Maintainer,

diagnostics fails to build from source in unstable/amd64:

  [..]

  /bin/bash ../../../libtool  --tag=CXX   --mode=link x86_64-linux-gnu-g++ -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic 
-Wno-unused-function   -Wl,-z,relro -lACE -lpthread -o use_case use_case.t.o 
../../../diagnostics/libdiagnostics.la 
  libtool: link: x86_64-linux-gnu-g++ -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -pedantic -Wno-unused-function -Wl,-z -Wl,relro 
-o .libs/use_case use_case.t.o  -lACE -lpthread 
../../../diagnostics/.libs/libdiagnostics.so
  make[11]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace'
  /usr/bin/make  check-TESTS
  make[11]: Entering directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace'
  make[12]: Entering directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace'
  ../../../config/runtest.sh: 17: ../../../config/runtest.sh: 
/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace//bin/bash:
 not found
  Makefile:1042: recipe for target 'stacktrace.log' failed
  make[12]: *** [stacktrace.log] Error 127
  make[12]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace'
  Makefile:1021: recipe for target 'check-TESTS' failed
  make[11]: *** [check-TESTS] Error 2
  make[11]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace'
  Makefile:1126: recipe for target 'check-am' failed
  make[10]: *** [check-am] Error 2
  make[10]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace'
  Makefile:808: recipe for target 'check-recursive' failed
  make[9]: *** [check-recursive] Error 1
  make[9]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace'
  Makefile:1129: recipe for target 'check' failed
  make[8]: *** [check] Error 2
  make[8]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions/stacktrace'
  Makefile:427: recipe for target 'check-recursive' failed
  make[7]: *** [check-recursive] Error 1
  make[7]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions'
  Makefile:576: recipe for target 'check' failed
  make[6]: *** [check] Error 2
  make[6]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics/extensions'
  Makefile:816: recipe for target 'check-recursive' failed
  make[5]: *** [check-recursive] Error 1
  make[5]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics'
  Makefile:1130: recipe for target 'check' failed
  make[4]: *** [check] Error 2
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3/diagnostics'
  Makefile:537: recipe for target 'check-recursive' failed
  make[3]: *** [check-recursive] Error 1
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3'
  Makefile:829: recipe for target 'check' failed
  make[2]: *** [check] Error 2
  make[2]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3'
  debian/rules:34: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 2
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160413100650.PbLGfnZiRs.diagnostics/diagnostics-0.3.3'
  debian/rules:15: recipe for target 'build' failed
  make: *** [build] Error 2

  [..]

The full build log is attached.


Regards,

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


diagnostics.0.3.3-11.unstable.amd64.log.txt.gz
Description: Binary data

Bug#820866: r-cran-tgp: FTBFS: cmath:171:3: error: template with C linkage

[Chris Lamb]

Source: r-cran-tgp
Version: 2.4-9-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

r-cran-tgp fails to build from source in unstable/amd64:

  [..]

  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:171:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::ceil(long double)':
  /usr/include/c++/5/cmath:188:23: error: conflicting declaration of C function 
'long double std::ceil(long double)'
 ceil(long double __x)
 ^
  /usr/include/c++/5/cmath:184:3: note: previous declaration 'float 
std::ceil(float)'
 ceil(float __x)
 ^
  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:192:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::cos(long double)':
  /usr/include/c++/5/cmath:207:22: error: conflicting declaration of C function 
'long double std::cos(long double)'
 cos(long double __x)
^
  /usr/include/c++/5/cmath:203:3: note: previous declaration 'float 
std::cos(float)'
 cos(float __x)
 ^
  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:211:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::cosh(long double)':
  /usr/include/c++/5/cmath:226:23: error: conflicting declaration of C function 
'long double std::cosh(long double)'
 cosh(long double __x)
 ^
  /usr/include/c++/5/cmath:222:3: note: previous declaration 'float 
std::cosh(float)'
 cosh(float __x)
 ^
  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:230:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::exp(long double)':
  /usr/include/c++/5/cmath:245:22: error: conflicting declaration of C function 
'long double std::exp(long double)'
 exp(long double __x)
^
  /usr/include/c++/5/cmath:241:3: note: previous declaration 'float 
std::exp(float)'
 exp(float __x)
 ^
  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:249:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::fabs(long double)':
  /usr/include/c++/5/cmath:264:23: error: conflicting declaration of C function 
'long double std::fabs(long double)'
 fabs(long double __x)
 ^
  /usr/include/c++/5/cmath:260:3: note: previous declaration 'float 
std::fabs(float)'
 fabs(float __x)
 ^
  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:268:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::floor(long double)':
  /usr/include/c++/5/cmath:283:24: error: conflicting declaration of C function 
'long double std::floor(long double)'
 floor(long double __x)
  ^
  /usr/include/c++/5/cmath:279:3: note: previous declaration 'float 
std::floor(float)'
 floor(float __x)
 ^
  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:287:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::fmod(long double, 
long double)':
  /usr/include/c++/5/cmath:302:40: error: conflicting declaration of C function 
'long double std::fmod(long double, long double)'
 fmod(long double __x, long double __y)
  ^
  /usr/include/c++/5/cmath:298:3: note: previous declaration 'float 
std::fmod(float, float)'
 fmod(float __x, float __y)
 ^
  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:306:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::frexp(long double, 
int*)':
  /usr/include/c++/5/cmath:323:36: error: conflicting declaration of C function 
'long double std::frexp(long double, int*)'
 frexp(long double __x, int* __exp)
  ^
  /usr/include/c++/5/cmath:319:3: note: previous declaration 'float 
std::frexp(float, int*)'
 frexp(float __x, int* __exp)
 ^
  /usr/include/c++/5/cmath: At global scope:
  /usr/include/c++/5/cmath:327:3: error: template with C linkage
 template
 ^
  /usr/include/c++/5/cmath: In function 'long double std::ldexp(long double, 
int)':
  /usr/include/c++/5/cmath:342:35: error: conflicting declaration of C function 
'long double std::ldexp(long double, int)'
 ldexp(long double __x, int __exp)
 ^
  /usr/include/c++/5/cmath:338:3: note: previous declaration 'float 
std::ldexp(float, int)'
 ldexp(float __x, int __exp)
 ^
  /usr/include/c++/5/cmath: At global sco

Bug#820867: reprepro: Please allow to apply overrides on already installed packages

[Raphaël Hertzog]

Package: reprepro
Version: 4.17.0-1
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

For some reasons it seems that "update" + "pull" rules do not properly
transfer the priority... for instance I have the emdebian-archive-keyring
which is priority extra in Debian's Packages files but priority important
in the .deb itself. And it ended up as priority important in the Kali
archive...

Now I want to fix this priority so I added the "DebOverride" directive
to conf/distributions but the next "export" does not apply this updated
priority. Instead I have to remove the package and add it back to get
it applied.

It would be nice if the overrides could either be automatically applied
or at least have a command to apply them without requiring such trickery.

Cheers,

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

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

Versions of packages reprepro depends on:
ii  libarchive13 3.1.2-11+b1
ii  libbz2-1.0   1.0.6-8
ii  libc62.22-6
ii  libdb5.3 5.3.28-11
ii  libgpg-error01.21-2
ii  libgpgme11   1.6.0-1
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  pinentry-curses  0.9.7-5
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages reprepro recommends:
ii  apt  1.2.10

Versions of packages reprepro suggests:
ii  gnupg-agent  2.1.11-6
pn  inoticoming  
pn  lzip 

-- no debconf information

Bug#725629: vice: racy build

[Andreas Beckmann]

On 2016-04-11 09:29, László Böszörményi (GCS) wrote:
> On Mon, Apr 11, 2016 at 9:15 AM, Andreas Beckmann  wrote:
>> [ this analysis is has been superseded by bug #820658 I filed against make ]
>  Yeah, just read that. Do you think anything will happen on the side
> of make? Especially as below you can be right that filesystem
> timestamp resolution is the real problem.

Closed, wontfix, is documented.

If more upstreams use the same pattern I would expect to see this bug
more frequently in the future.

Upstream's approach of recursively updating the Makefile depending on
itself looks a bit weird. How do other projects that use the po-foo
(with POTFILES.in, Makefile.in.in, ...) handle this?


Andreas

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

[Tobias Frost]

Am 13. April 2016 10:33:28 MESZ, schrieb "László Böszörményi (GCS)" 
:
>Hi Tobias,
>
>On Wed, Apr 13, 2016 at 9:39 AM, Tobias Frost  wrote:
>> Package: vice
>> Followup-For: Bug #725629
>>
>> I'm currently rebuilding vice in a loop on fischer.debian.org with
>both patches applied and it looks quite good so far.
>>
>> As I'd like to push things (especially the libpng1.6 transition)
>forward, I will NMU if successful.
>If possible, please send a patch instead. I can do a normal upload
>fast.
>
>Cheers,
>Laszlo/GCS

I just applied both patches from the BTs.
-- 
Tobias Frost

13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7

Bug#820868: rsync: Using --fake-super breaks creation of symlinks

[Chris Davies]

Package: rsync
Version: 3.1.1-3
Severity: important

Dear Maintainer,

Running rsync with --fake-server, copying from a remote system to the
local system. Symbolic links are now created as standard files containing
the symbolic link target filename. This renders them useless.


Scenario

1. Source files on remote host (ls -l /etc/openldap). There's nothing
special about this directory. The symlinks point outside the directory
tree being copied, but this makes no difference to the problem described
here.

-rw-r--r--1 adminadminist   263 Jan 31 02:14 ldap.conf
lrwxrwxrwx1 adminadminist44 Feb 28 16:04 schema -> 
/mnt/ext/opt/ldap_server/etc/openldap/schema
lrwxrwxrwx1 adminadminist31 Feb 28 03:07 slapd.conf -> 
/etc/config/openldap/slapd.conf
lrwxrwxrwx1 adminadminist34 Feb 28 03:07 slapdacl.conf -> 
/etc/config/openldap/slapdacl.conf


2. Operation and resulting files using rsync 3.1.1 WITHOUT --fake-super. This 
works as expected.

rsync -v -azS --delete --delete-excluded --numeric-ids 
remote_host:/etc/openldap/ .
receiving incremental file list
./
ldap.conf
schema -> /mnt/ext/opt/ldap_server/etc/openldap/schema
slapd.conf -> /etc/config/openldap/slapd.conf
slapdacl.conf -> /etc/config/openldap/slapdacl.conf

sent 42 bytes  received 462 bytes  91.64 bytes/sec
total size is 372  speedup is 0.74

ls -l
total 4
-rw-r--r-- 1 root root 263 Jan 30 13:14 ldap.conf
lrwxrwxrwx 1 root root  44 Feb 28 03:04 schema -> 
/mnt/ext/opt/ldap_server/etc/openldap/schema
lrwxrwxrwx 1 root root  34 Feb 27 14:07 slapdacl.conf -> 
/etc/config/openldap/slapdacl.conf
lrwxrwxrwx 1 root root  31 Feb 27 14:07 slapd.conf -> 
/etc/config/openldap/slapd.conf


3. Operation and resulting files using rsync 3.1.1 USING --fake-super. This 
fails to create symlinks.

rsync -v -azS --delete --delete-excluded --numeric-ids --fake-super 
remote_host:/etc/openldap/ .
receiving incremental file list
./
ldap.conf
schema -> /mnt/ext/opt/ldap_server/etc/openldap/schema
slapd.conf -> /etc/config/openldap/slapd.conf
slapdacl.conf -> /etc/config/openldap/slapdacl.conf

sent 42 bytes  received 462 bytes  91.64 bytes/sec
total size is 372  speedup is 0.74

ls -l
total 16
-rw-r--r-- 1 root root 263 Jan 30 13:14 ldap.conf
-rwxrwxrwx 1 root root  44 Feb 28 03:04 schema
-rwxrwxrwx 1 root root  34 Feb 27 14:07 slapdacl.conf
-rwxrwxrwx 1 root root  31 Feb 27 14:07 slapd.conf


4. Regression with rsync 3.0.9 (Debian wheezy) USING --fake-super. This works 
as expected.

rsync -v -azS --delete --delete-excluded --numeric-ids --fake-super 
remote_host:/etc/openldap/ .
receiving incremental file list
./
ldap.conf
schema -> /mnt/ext/opt/ldap_server/etc/openldap/schema
slapd.conf -> /etc/config/openldap/slapd.conf
slapdacl.conf -> /etc/config/openldap/slapdacl.conf

sent 42 bytes  received 462 bytes  77.54 bytes/sec
total size is 372  speedup is 0.74

ls -l
total 4
-rw-r--r-- 1 root root 263 Jan 30 13:14 ldap.conf
lrwxrwxrwx 1 root root  44 Feb 28 03:04 schema -> 
/mnt/ext/opt/ldap_server/etc/openldap/schema
lrwxrwxrwx 1 root root  34 Feb 27 14:07 slapdacl.conf -> 
/etc/config/openldap/slapdacl.conf
lrwxrwxrwx 1 root root  31 Feb 27 14:07 slapd.conf -> 
/etc/config/openldap/slapd.conf


Thanks.


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

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

Versions of packages rsync depends on:
ii  base-files  9.6
ii  libacl1 2.2.52-3
ii  libattr11:2.4.47-2
ii  libc6   2.22-5
ii  libpopt01.16-10
ii  lsb-base9.20160110

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.2p2-2
ii  openssh-server  1:7.2p2-2

-- no debconf information

Bug#820870: Error when installing emacs24 elisp files

[Yuri D'Elia]

Package: gforth
Version: 0.7.3+dfsg-2
Severity: normal

Setting up gforth (0.7.3+dfsg-2) ...
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Install gforth for emacs24
install/gforth: Handling install for emacsen flavor emacs24

Error occurred processing *.el: File error (("Opening input file" "no such file or 
directory" "/usr/share/emacs24/site-lisp/gforth/*.el"))

Wrote /usr/share/emacs24/site-lisp/gforth/path.elc
ERROR: install script from gforth package failed
dpkg: error processing package gforth (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
gforth
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up gforth (0.7.3+dfsg-2) ...
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Install gforth for emacs24
install/gforth: Handling install for emacsen flavor emacs24

Error occurred processing *.el: File error (("Opening input file" "no such file or 
directory" "/usr/share/emacs24/site-lisp/gforth/*.el"))

Wrote /usr/share/emacs24/site-lisp/gforth/path.elc
ERROR: install script from gforth package failed
dpkg: error processing package gforth (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
gforth

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

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

Versions of packages gforth depends on:
ii  emacsen-common  2.0.8
ii  gforth-common   0.7.3+dfsg-2
ii  gforth-lib  0.7.3+dfsg-2
ii  libc6   2.22-6
ii  libffi6 3.2.1-4
ii  libltdl72.4.6-0.1

gforth recommends no packages.

gforth suggests no packages.

Bug#820869: pyexiv2: please make the build reproducible (timestamps)

[Alexis Bienvenüe]

Source: pyexiv2
Version: 0.3.2-8
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

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

The attached patch honours the SOURCE_DATE_EPOCH environment variable
through the ustrftime function, to get a reproducible copyright year.
Once applied, pyexiv2 can be built reproducibly in our current
experimental framework.

Regards,
Alexis Bienvenüe.

 [1]: https://wiki.debian.org/ReproducibleBuilds




diff -Nru pyexiv2-0.3.2/debian/changelog pyexiv2-0.3.2/debian/changelog
--- pyexiv2-0.3.2/debian/changelog	2015-04-28 11:26:28.0 +0200
+++ pyexiv2-0.3.2/debian/changelog	2016-04-13 11:31:43.0 +0200
@@ -1,3 +1,10 @@
+pyexiv2 (0.3.2-8.0~reproducible1) unstable; urgency=medium
+
+  * Get copyright year from ustrftime for documentation, to make the build
+reproducible.
+
+ -- Alexis Bienvenüe   Wed, 13 Apr 2016 11:31:43 +0200
+
 pyexiv2 (0.3.2-8) unstable; urgency=medium
 
   * Adjust Vcs-Svn URL.
diff -Nru pyexiv2-0.3.2/debian/patches/series pyexiv2-0.3.2/debian/patches/series
--- pyexiv2-0.3.2/debian/patches/series	2015-04-28 11:22:29.0 +0200
+++ pyexiv2-0.3.2/debian/patches/series	2016-04-13 10:58:31.0 +0200
@@ -1 +1,2 @@
 remove-date.patch
+use_source_date_for_copyright.patch
diff -Nru pyexiv2-0.3.2/debian/patches/use_source_date_for_copyright.patch pyexiv2-0.3.2/debian/patches/use_source_date_for_copyright.patch
--- pyexiv2-0.3.2/debian/patches/use_source_date_for_copyright.patch	1970-01-01 01:00:00.0 +0100
+++ pyexiv2-0.3.2/debian/patches/use_source_date_for_copyright.patch	2016-04-13 11:00:34.0 +0200
@@ -0,0 +1,25 @@
+Description: Use source date for copyright year
+ To get copyright year, use ustrftime, which honours SOURCE_DATE_EPOCH.
+ This makes the build reproducible.
+ See https://reproducible-builds.org/specs/source-date-epoch/
+Author: Alexis Bienvenüe 
+
+--- pyexiv2-0.3.2.orig/doc/conf.py
 pyexiv2-0.3.2/doc/conf.py
+@@ -14,6 +14,7 @@
+ import sys, os
+ import time
+ import pyexiv2
++from sphinx.util.osutil import ustrftime
+ 
+ # If extensions (or modules to document with autodoc) are in another directory,
+ # add these directories to sys.path here. If the directory is relative to the
+@@ -40,7 +41,7 @@ master_doc = 'index'
+ 
+ # General information about the project.
+ project = u'pyexiv2'
+-copyright = u'2006-%s, Olivier Tilloy' % time.strftime('%Y')
++copyright = u'2006-%s, Olivier Tilloy' % ustrftime('%Y')
+ 
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the

Bug#819979: libgit2 transition pending, now in experimental.

[Andreas Henriksson]

Hello all again!

On Mon, Apr 11, 2016 at 05:34:59PM +0200, Andreas Henriksson wrote:
> Hello Dmitry, Pirate.
> 
> The new libgit2 0.24.0 has just cleared NEW and should soon be available
> in the archive. If it has not yet reached your mirror I've put a copy of
> it at https://people.debian.org/~ah/libgit2/ for your convenience.
> 
> It would be great if you could do an upload of your packages
[...]

Thanks to quick actions from Dmitry and Pirate everything is now available
in experimental.

I've just uploaded the new libgit2 to unstable kicking off this transition!

Release team, please spin up the binNMUs for everything except
libgit2-glib and ruby-rugged which will have sourceful uploads.

(Please also note that geany-plugins FTBFS has just been fixed
and have not yet transitioned to testing yet.)

Dmitry, Pirate please upload your packages to unstable at your convenience.

The auto tracker is now also available at:
https://release.debian.org/transitions/html/auto-libgit2.html

Regards,
Andreas Henriksson

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Jan Henke]

Free Software also means the freedom of choice. Yes, using free software is 
preferably, but not always we can do that. This package's main purpose is to 
enable non-free software to integrate as good as possible into Debian. You have 
to acknowledge there is non-free software in the world and it is being used, 
sometimes deliberately.

I opened this bug not just for myself, but to ask for something, that in my 
opinion constitutes an improvement to this package and helps other people as 
well. After I have been following the Java mailing lists for quite some time, I 
am disappointed about this (in my opinion) aggressive replies to this bug.

I really appreciate Emanuel's suggestion, which would really solve the problem 
for me and also keep the current default for everyone else. Having the chance 
to make the new package the default simplifies the process for many people. It 
keeps the current default and those, who will use the extra parameter, would 
use the proprietary JDK as default anyway. So I fail to see where that harms 
the free software. It just makes the life easier for some people.

Can we agree on adding Emanuel's proposal as an additional option and otherwise 
refrain from ideological discussion about free vs non-free software please?

Best Regards,
Jan Henke



Jan Henke | Softwareentwickler
Hugendubel Digital GmbH & Co. KG
Friesenweg 1 | D-22763 Hamburg
Telefon: +49 (0)40 851 94 - 109 | Telefax: +49 (0)40 851 94 - 113
E-Mail: jhe...@hugendubel-digital.de

www.hugendubel.de – Die Welt der Bücher
www.eBook.de – Meine Bücher immer dabei
_

Geschäftsführung: Per Dalheimer, Dr. Stefan Höllermann
Umsatzsteuer ID: DE300667265 | AG Hamburg HRA 118925
_

-Original Message-
From: Markus Koschany [mailto:a...@debian.org]
Sent: Wednesday, April 13, 2016 11:02 AM
To: Jan Henke
Cc: 820...@bugs.debian.org
Subject: Re: Bug#820857: java-package: Generated JDK package should have higher 
priority than existing openjdk packages

Am 13.04.2016 um 10:32 schrieb Jan Henke:
> Hi,
>
> I would prefer this. An extra option while creating the package to give it 
> the highest priority.
>
> Markus, while in principle I agree with you, sadly my job requires me to use 
> the propritary JDK. I do think this use case should be as simple as possible 
> and not made more difficult "because it is non free software".
>
> Best Regards,
> Jan Henke

I also have to use the proprietary JDK from time to time to test my
software. However I think Debian is about free software and everything
we do should reflect this and thus OpenJDK was made the default JDK/JRE.

I also don't see the difficulties in using

sudo update-alternatives --config java


after the installation of the Oracle JDK and to change the default to
the preferred one. That would have taken less time than to file this bug
report.

Regards,

Markus

Bug#806555: evince: SEGFAULT when opening a specific PDF, but other poppler-based viewers don't segfault

[Jason Crain]

reassign 806555 cairo 1.14.0-2.1
fixed 806555 1.14.4-1
tags 806555 + patch
forwarded 806555 https://bugs.freedesktop.org/show_bug.cgi?id=74779
thanks

Was fixed by this commit in cairo:
https://cgit.freedesktop.org/cairo/commit/?id=9f2bbfa41fa26a44c38949ecf329b06b5585c87c

as part of bug:
https://bugs.freedesktop.org/show_bug.cgi?id=74779

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

[GCS]

On Wed, Apr 13, 2016 at 11:32 AM, Tobias Frost  wrote:
> Am 13. April 2016 10:33:28 MESZ, schrieb "László Böszörményi (GCS)"
> :
>> On Wed, Apr 13, 2016 at 9:39 AM, Tobias Frost  wrote:
>>>  As I'd like to push things (especially the libpng1.6 transition)
>>> forward, I will NMU if successful.
>>
>>  If possible, please send a patch instead. I can do a normal upload fast.
>
> I just applied both patches from the BTs.
 OK, I see. Ping me when you finished your tests and those didn't
failed. I'm going to eat sooner or later, but will do the upload as
soon as I can.

Thanks for your time,
Laszlo/GCS

Bug#819288: /tmp is used before /tmp being mounted

[François Scala]

Hello,

While working on a Debian installation base on a ZFS root filesystem 
with LUKS encryption I've encountered a problem with keyboard-setup init 
script that create file in /tmp before /tmp being mounted.


I've write a small script to dump some information just before the "zfs 
mount -a" command.


Here is the process tree

|-keyboard-setup,1334 /etc/init.d/keyboard-setup start
|   `-setupcon,1336 /bin/setupcon -k
|   `-ckbcomp,1387 /usr/bin/ckbcomp -backspace del -model pc105 us

And opened file in /tmp :

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
setupcon 1336 root1w   REG   0,160 49551 /tmp/tmpkbd.6Vr3KX
ckbcomp  1387 root1w   REG   0,160 49551 /tmp/tmpkbd.6Vr3KX

Regards.

François.

Bug#820871: e2fsprogs: unable to fix ext4 file system with unavailable external journal

[Dmitry Smirnov]

Package: e2fsprogs
Version: 1.42.12-1.1
Severity: important

I have an ext4 file system with external journal.
Journal device died and file system is in RO mode.

In order to switch back to internal journal I need to remove reference to 
external journal, run fsck and re-create journal:

tune2fs -O ^has_journal /dev/md2


The needs_recovery flag is set. Please run e2fsck before clearing.


fsck.ext4 -C0 /dev/md2


e2fsck 1.42.12 (29-Aug-2014)
tmp: Attempt to read block from filesystem resulted in short read while 
reading block 0

fsck.ext4: Attempt to read block from filesystem resulted in short read while 
checking ext3 journal for tmp

tmp: ** WARNING: Filesystem still has errors **


(fsck fails with "-E journal_only" as well).

tune2fs -O ^needs_recovery /dev/md2


Clearing filesystem feature 'needs_recovery' not supported.


As you can see there is a deadlock: I can't remove reference to non existent 
external journal before running _fsck_ which refuses to work when journal is 
not available. Catch-22?

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

Do your duty as you see it, and damn the consequences.
-- George S. Patton


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

Bug#820010: [PATCH v2] libkmod: Add support for detached module signatures

[Ben Hutchings]

On Wed, 2016-04-13 at 01:05 -0300, Lucas De Marchi wrote:
> Hi,
> 
> CC'ing Rusty
> 
> On Mon, Apr 4, 2016 at 9:32 PM, Ben Hutchings  wrote:
> > 
> > Debian will not sign modules during the kernel package build, as this
> > conflicts with the goal of reproducible builds.  Instead, we will
> > generate detached signatures offline and include them in a second
> > package.
> Is this a decision already? It doesn't look as a good reason - you
> would already need to provide a signing key (CONFIG_MODULE_SIG_KEY)
> anyway for this to work. How is leaving the module signature in
> another package be any better than just signing the module?  If you
> have the signature, the build is just as reproducible as before.

I think we may have different ideas about what reproducibility means.
When I say reproducible I mean *anyone* with the right tools installed
can reproduce the binary packages (.deb) from the source package (.dsc
and tarballs).

The signing key obviously isn't available to everyone, so the source
package has to include detached signatures prepared outside of the
package build process.  But we can't put them in the linux source
package, because that results in a dependency loop.

> > 
> > We could attach the signatures when building this second package or at
> > installation time, but that leads to duplication of all modules,
> > either in the archive or on users' systems.
> > 
> > To avoid this, add support to libkmod for concatenating modules with
> > detached signatures (files with the '.sig' extension) at load time.
> this has the drawback that finit_module() can't be used.

So does module compression, but it's still a supported option.

[...]
> > +   /* Try to open a detached signature.  If it's missing, that's OK. */
> > +   if (asprintf(&sig_filename, "%s.sig", filename) < 0) {
> > +   err = -errno;
> > +   goto error;
> > +   }
> > +   file->sig_fd = open(sig_filename, O_RDONLY|O_CLOEXEC);
> > +   if (file->sig_fd < 0 && errno != ENOENT) {
> > +   err = -errno;
> > +   goto error;
> > +   }
> This can't really work if the module is being loaded uncompressed (I
> think nowadays we can even add support for compressed modules...
> Rusty, any input here?).
>
> When the module is being directly loaded, the direct flag gets set so
> kmod_module_insert_module() knows it can try to use finit_module().
> Since you have an external signature what would happen is that we
> would load the signature, but try to load the module in the kernel
> without it.

It does work.  I changed load_reg() to disable direct loading.when
there's a detached signature.

Ben.

> I'm still not convinced the split module + signature is actually a good thing.
> 
> 
> Lucas De Marchi
-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.

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

Bug#820733: Guidelines for sensible package synopsis (was: Bug#820733: RFS: Series/1.0 [ITP] -- Keep track of your favourite TV series)

[Gianfranco Costamagna]

Hi again,

stuff to do:

fix lintian, make a real copyright file, fix flags, fix useless files, convert 
the format to quilt...

come back if you don't know how to fix issues, when you have a larger userbase, 
and when you learn how
to tag release, remove useless stuff and *not* commit binaries on git :)


and the package has to build on a clean pbuilder/sbuild environment


there is a lot of work to do here!
(I suggest you to go on irc oftc and ask on -mentors, or click on the link on 
mentors website, each
lintian warning has an explanation that helps in fixing it)


cheers,

G.


Il Martedì 12 Aprile 2016 20:57, Giorgio Sartore  ha 
scritto:



Hi Gianfranco,
thank you for your answer. I've uploaded the package to 
https://mentors.debian.net/package/series
I'm almost sure I made a few mistakes, so please tell me what to do to fix them.
Best regards
Giorgio
Il 12/apr/2016 14:28, "Gianfranco Costamagna"  ha 
scritto:

Hi Giorgio
>
>
>http://mentors.debian.net/intro-maintainers
>
>this should help.
>
>
>cheers,
>
>G.
>
>
>Il Martedì 12 Aprile 2016 13:36, Giorgio Sartore  ha 
>scritto:
>
>
>
>Hi all,
>thank you for your hints. I'll update the synopsis as soon as possibile.
>I know that I've uploaded the source code yesterday, but I'm working on it 
>since about a month, in my free time. The project started as a personal 
>program, recently I thought that it could be useful to other people. So, I'd 
>like to share it with all Debian users.
>Anyway, can you please guide me through this process? It's my first time. May 
>I have some chances to get it published?
>Thank you very much.
>Regards,
>Giorgio
>Il 12/apr/2016 07:30, "Ben Finney"  ha scritto:
>
>Tiago Ilieve  writes:
>>
>>> Hi Sartore,
>>>
>>> On 11 April 2016 at 16:36, Sartore Giorgio (Mani)  
>>> wrote:
>>> > series - keep track of your favourite TV series
>>>
>>> […] I would like to ask you to close this bug and open a new one when
>>> the package is more mature and have a few more users.
>>
>>When starting that Debian package, please follow the guidelines for the
>>package description.
>>
>>For example:
>>
>>frobnicator of grellicules
>>
>>The test to apply is detailed in the Developer's Reference §6.2.2:
>>
>>Technically this is a noun phrase minus articles, as opposed to a
>>verb phrase. A good heuristic is that it should be possible to
>>substitute the package name and synopsis into this formula:
>>
>>The package ‘name’ provides {a,an,the,some} synopsis.
>>
>>So, the synopsis “keep track of your favourite TV series” makes that
>>sentence:
>>
>>The package ‘series’ provides a keep track of your favourite TV series.
>>
>>This doesn't make sense, and so the synopsis should be re-written to be
>>a noun phrase.
>>
>>--
>> \   “It is a part of probability that many improbable things will |
>>  `\   happen.” —Aristotle, _Poetics XXV_, 335 BCE |
>>_o__)  |
>>Ben Finney 
>>
>

Bug#820873: amule: An assertion failed! (kademlia)

[ZenWalker]

Package: amule
Version: 2.4.0~git20151120.0023527bc2-1+b2
Severity: normal

Control: tags -1 patch upstream fixed-upstream
Control: forwarded -1 https://github.com/amule-project/amule/issues/28

Dear Maintainer,

Please apply this patch.

It solves this issue:

https://github.com/amule-project/amule/issues/28

With this commit:

https://github.com/amule-
project/amule/commit/786a00b1ea0f6100b591cc5c1d93658af2770919



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

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

Versions of packages amule depends on:
ii  amule-common   2.4.0~git20151120.0023527bc2-1
ii  libboost-system1.58.0  1.58.0+dfsg-5+b1
ii  libc6  2.22-5
ii  libcrypto++6   5.6.3-5
ii  libgcc11:5.3.1-13
ii  libgeoip1  1.6.9-1
ii  libstdc++6 5.3.1-13
ii  libupnp6   1:1.6.19+git20160116-1
ii  libwxbase3.0-0v5   3.0.2+dfsg-1.3
ii  libwxgtk3.0-0v53.0.2+dfsg-1.3
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages amule recommends:
ii  amule-utils  2.4.0~git20151120.0023527bc2-1+b2
ii  unzip6.0-20

Versions of packages amule suggests:
pn  amule-utils-gui  

-- no debconf information

Bug#820872: eclipse: Display problem in install window and hereby not possible to install eny items

[treaki]

Package: eclipse
Version: 3.8.1-7
Severity: important

Hi folks,

i have tried everything i can (including starting a completely hardware 
independent Xserver without my normal (very user defined) grafical env.

But there is still this display problem which prevents me from installing items 
using the buildin install system.

See the screenshot, there where the list should be is nothing...

in debian 6 worked everything grate, in debian 7 the system was still stable 
but now with debian 8. everytime problems like this.

Please keep debian as an universal system and dont move to server only as it 
lookes like for me!

thanks in advance for fixing that problem

regards treaki


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

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

Versions of packages eclipse depends on:
ii  eclipse-jdt  3.8.1-7
ii  eclipse-pde  3.8.1-7

eclipse recommends no packages.

eclipse suggests no packages.

Versions of packages eclipse-platform depends on:
ii  ant1.9.4-3
ii  ant-optional   1.9.4-3
ii  default-jre [java6-runtime]2:1.7-52
ii  eclipse-platform-data  3.8.1-7
ii  eclipse-rcp3.8.1-7
ii  gconf-service  3.2.6-3
ii  java-common0.52
ii  libc6  2.19-18+deb8u4
ii  libcommons-codec-java  1.9-1
ii  libcommons-httpclient-java 3.1-11+deb8u1
ii  libcommons-logging-java1.2-1
ii  libgconf-2-4   3.2.6-3
ii  libglib2.0-0   2.42.1-1+b1
ii  libjetty8-java 8.1.16-4
ii  libjsch-java   0.1.51-1
ii  liblucene2-java2.9.4+ds1-4
ii  libservlet3.0-java 7.0.56-3+deb8u1
ii  multiarch-support  2.19-18+deb8u4
ii  openjdk-6-jre [java6-runtime]  6b35-1.13.7-1~deb7u1
ii  openjdk-7-jre [java6-runtime]  7u95-2.6.4-1~deb8u1
ii  sat4j  2.3.3-1

Versions of packages eclipse-platform recommends:
ii  eclipse-pde  3.8.1-7

Versions of packages eclipse-platform suggests:
ii  eclipse-jdt  3.8.1-7

Versions of packages eclipse-pde depends on:
ii  default-jre [java6-runtime]2:1.7-52
ii  eclipse-jdt3.8.1-7
ii  eclipse-platform   3.8.1-7
ii  libasm3-java   3.3.2-2
ii  openjdk-6-jre [java6-runtime]  6b35-1.13.7-1~deb7u1
ii  openjdk-7-jre [java6-runtime]  7u95-2.6.4-1~deb8u1

eclipse-pde suggests no packages.

Versions of packages eclipse-jdt depends on:
ii  default-jre [java6-runtime]2:1.7-52
ii  eclipse-platform   3.8.1-7
ii  junit  3.8.2-8
ii  junit4 4.11-3
ii  libhamcrest-java   1.3-5
ii  openjdk-6-jre [java6-runtime]  6b35-1.13.7-1~deb7u1
ii  openjdk-7-jre [java6-runtime]  7u95-2.6.4-1~deb8u1

Versions of packages eclipse-jdt recommends:
ii  default-jdk  2:1.7-52

eclipse-jdt suggests no packages.

-- no debconf information

Bug#820873: (no subject)

[ZenWalker]

here is the patch

best regardsdiff --git a/src/kademlia/net/KademliaUDPListener.cpp b/src/kademlia/net/KademliaUDPListener.cpp
index 084eef5..af60f17 100644
--- a/src/kademlia/net/KademliaUDPListener.cpp
+++ b/src/kademlia/net/KademliaUDPListener.cpp
@@ -524,7 +524,9 @@ void CKademliaUDPListener::Process2HelloRequest(const uint8_t *packetData, uint3
 	uint8_t contactVersion = 0;
 	CUInt128 contactID;
 	bool addedOrUpdated = AddContact2(packetData, lenPacket, ip, port, &contactVersion, senderKey, validReceiverKey, true, true, NULL, &contactID); // might change (udp)port, validReceiverKey
-	wxASSERT(contactVersion >= 2);
+	if (contactVersion < 2) {
+		throw wxString(CFormat(wxT("***NOTE: Received invalid Kademlia2 version (%u) in %s")) % contactVersion % wxString::FromAscii(__FUNCTION__));
+	}
 #ifdef __DEBUG__
 	if (dbgOldUDPPort != port) {
 		AddDebugLogLineN(logClientKadUDP, CFormat(wxT("KadContact %s uses his internal (%u) instead external (%u) UDP Port")) % KadIPToString(ip) % port % dbgOldUDPPort);
@@ -1650,7 +1652,6 @@ void CKademliaUDPListener::SendLegacyChallenge(uint32_t ip, uint16_t port, const
 	CUInt128 challenge(GetRandomUint128());
 	if (challenge == 0) {
 		// hey there is a 2^128 chance that this happens ;)
-		wxFAIL;
 		challenge = 1;
 	}
 	// Put the target we want into the packet. This is our challenge
diff --git a/src/kademlia/routing/RoutingZone.cpp b/src/kademlia/routing/RoutingZone.cpp
index 7fedf53..3887090 100644
--- a/src/kademlia/routing/RoutingZone.cpp
+++ b/src/kademlia/routing/RoutingZone.cpp
@@ -270,7 +270,6 @@ void CRoutingZone::ReadBootstrapNodesDat(CFileDataIO& file)
 			}
 		}
 		if (!inserted) {
-			wxASSERT(CKademlia::s_bootstrapList.size() < 50);
 			CKademlia::s_bootstrapList.push_back(contact);
 		} else if (CKademlia::s_bootstrapList.size() > 50) {
 			delete CKademlia::s_bootstrapList.back();
@@ -811,6 +810,7 @@ void CRoutingZone::OnSmallTimer()
 			CKademlia::GetUDPListener()->SendMyDetails(KADEMLIA2_HELLO_REQ, c->GetIPAddress(), c->GetUDPPort(), c->GetVersion(), 0, NULL, false);
 			wxASSERT(c->GetUDPKey() == CKadUDPKey(0));
 		} else {
+			AddDebugLogLineN(logKadRouting, CFormat(wxT("Ignoring Kad contact %s version %d.")) % KadIPToString(c->GetIPAddress()) % c->GetVersion());
 			//wxFAIL;	// thanks, I'm having enough problems without any Kad asserts
 		}
 	}

Bug#820152: anope: please make the build reproducible (timestamps)

[Dominic Hargreaves]

Control: tags -1 + confirmed
Control: forwarded -1 t...@anope.org

On Tue, Apr 05, 2016 at 11:28:36PM +0200, Alexis Bienvenüe wrote:
> While working on the “reproducible builds” effort [1], we have noticed
> that 'anope' could not be built reproducibly.
> 
> The attached patch removes build date from the version string. Once
> applied, anope can be built reproducibly in our current experimental
> framework.

Thanks for the patch. I've asked upstream whether they would be
happy with this approach, or a conditional approach where the build
date can be override by environment variables.

Cheers,
Dominic.

Bug#820874: gridengine-master: doesn't use invoke-rc.d

[Andreas Beckmann]

Package: gridengine-master
Version: 8.1.8+dfsg-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package starts processes
where it shouldn't. This is very probably due to not using invoke-rc.d
as mandated by policy 9.3.3.2. This is seriously disturbing! ;-)

See https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
and /usr/share/doc/sysv-rc/README.invoke-rc.d.gz as well
as /usr/share/doc/sysv-rc/README.policy-rc.d.gz

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

0m56.1s ERROR: FAIL: Processes are running inside chroot:
  COMMANDPID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
  sge_qmast 7083  151  rtdDIR   0,21  460 3014698734 
/tmp/piupartss/tmp2IrjI6
  sge_qmast 7083  151  memREG   0,21  1832240 3014713729 
/tmp/piupartss/tmp2IrjI6/usr/lib/x86_64-linux-gnu/libdb-5.3.so
  sge_qmast 7083  151  memREG   0,2184848 3014771244 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libresolv-2.22.so
  sge_qmast 7083  151  memREG   0,2122944 3014771220 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libnss_dns-2.22.so
  sge_qmast 7083  151  memREG   0,2147680 3014771235 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libnss_nis-2.22.so
  sge_qmast 7083  151  memREG   0,2189064 3014771209 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libnsl-2.22.so
  sge_qmast 7083  151  memREG   0,2131616 3014771219 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libnss_compat-2.22.so
  sge_qmast 7083  151  memREG   0,2147624 3014771229 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libnss_files-2.22.so
  sge_qmast 7083  151  memREG   0,21  1709784 3014768436 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libc-2.22.so
  sge_qmast 7083  151  memREG   0,21   135968 3014768352 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libpthread-2.22.so
  sge_qmast 7083  151  memREG   0,21  1038784 3014770967 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libm-2.22.so
  sge_qmast 7083  151  memREG   0,2114640 3014770966 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/libdl-2.22.so
  sge_qmast 7083  151  memREG   0,21   145096 3014768380 
/tmp/piupartss/tmp2IrjI6/lib/x86_64-linux-gnu/ld-2.22.so
  sge_qmast 7083  1510r   CHR1,3  0t0 3014712886 
/tmp/piupartss/tmp2IrjI6/dev/null
  sge_qmast 7083  1511w   CHR1,3  0t0 3014712886 
/tmp/piupartss/tmp2IrjI6/dev/null
  sge_qmast 7083  1512w   CHR1,3  0t0 3014712886 
/tmp/piupartss/tmp2IrjI6/dev/null


cheers,

Andreas


gridengine-master_8.1.8+dfsg-5.log.gz
Description: application/gzip

Bug#820875: redmine-plugin-custom-css: fails to install: redmine triggers fail

[Andreas Beckmann]

Package: redmine-plugin-custom-css
Version: 0.1.6+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Selecting previously unselected package redmine-plugin-custom-css.
  (Reading database ... 
(Reading database ... 16106 files and directories currently installed.)
  Preparing to unpack .../redmine-plugin-custom-css_0.1.6+dfsg-1_all.deb ...
  Unpacking redmine-plugin-custom-css (0.1.6+dfsg-1) ...
  Processing triggers for redmine (3.2.1-2) ...
  dbconfig-common: flushing administrative password
  rake aborted!
  Could not create directory 
/usr/share/redmine/public/plugin_assets/redmine_custom_css/javascripts: 
Permission denied @ dir_s_mkdir - 
/usr/share/redmine/public/plugin_assets/redmine_custom_css
  /usr/share/redmine/lib/redmine/plugin.rb:395:in `rescue in mirror_assets'
  /usr/share/redmine/lib/redmine/plugin.rb:392:in `mirror_assets'
  /usr/share/redmine/lib/redmine/plugin.rb:428:in `block in mirror_assets'
  /usr/share/redmine/lib/redmine/plugin.rb:427:in `each'
  /usr/share/redmine/lib/redmine/plugin.rb:427:in `mirror_assets'
  /usr/share/redmine/config/initializers/30-redmine.rb:23:in `'
  /usr/share/redmine/config/environment.rb:14:in `'
  Errno::EACCES: Permission denied @ dir_s_mkdir - 
/usr/share/redmine/public/plugin_assets/redmine_custom_css
  /usr/share/redmine/lib/redmine/plugin.rb:393:in `mirror_assets'
  /usr/share/redmine/lib/redmine/plugin.rb:428:in `block in mirror_assets'
  /usr/share/redmine/lib/redmine/plugin.rb:427:in `each'
  /usr/share/redmine/lib/redmine/plugin.rb:427:in `mirror_assets'
  /usr/share/redmine/config/initializers/30-redmine.rb:23:in `'
  /usr/share/redmine/config/environment.rb:14:in `'
  Tasks: TOP => db:migrate => environment
  (See full trace by running task with --trace)
  dpkg: error processing package redmine (--unpack):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   redmine


cheers,

andreas


redmine-plugin-custom-css_0.1.6+dfsg-1.log.gz
Description: application/gzip

Bug#820869: pyexiv2: please make the build reproducible (timestamps)

[Michal Čihař]

Hi

Dne 13.4.2016 v 11:35 Alexis Bienvenüe napsal(a):
> Source: pyexiv2
> Version: 0.3.2-8
> Severity: wishlist
> Tags: patch upstream
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> While working on the “reproducible builds” effort [1], we have noticed
> that 'pyexiv2' could not be built reproducibly.
> 
> The attached patch honours the SOURCE_DATE_EPOCH environment variable
> through the ustrftime function, to get a reproducible copyright year.
> Once applied, pyexiv2 can be built reproducibly in our current
> experimental framework.

Thanks for the patch, however I'm not really sure if this fixing this
package is worth of the effort. This is dead upstream and I would like
to look at reverse dependencies if they can not switch to gexiv2
instead, I just yet haven't found time to do that...

-- 
Michal Čihař | http://cihar.com/ | https://weblate.org/



signature.asc
Description: OpenPGP digital signature

Bug#820876: ntfs-3g-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: ntfs-3g-dev
Version: 1:2015.3.14AR.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  sid -> experimental

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (usually somewhere in the middle...):

0m43.5s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/ntfs-3g-dev/changelog.Debian.gz (ntfs-3g-dev) != 
/usr/share/doc/ntfs-3g/changelog.Debian.gz (ntfs-3g)
/usr/share/doc/ntfs-3g-dev -> ntfs-3g
  /usr/share/doc/ntfs-3g-dev/changelog.gz (ntfs-3g-dev) != 
/usr/share/doc/ntfs-3g/changelog.gz (ntfs-3g)
/usr/share/doc/ntfs-3g-dev -> ntfs-3g
  /usr/share/doc/ntfs-3g-dev/copyright (ntfs-3g-dev) != 
/usr/share/doc/ntfs-3g/copyright (ntfs-3g)
/usr/share/doc/ntfs-3g-dev -> ntfs-3g

0m45.3s ERROR: FAIL: debsums reports modifications inside the chroot:
  /usr/share/doc/ntfs-3g/changelog.Debian.gz
  /usr/share/doc/ntfs-3g/copyright


cheers,

Andreas


ntfs-3g-dev_1:2015.3.14AR.3-1.log.gz
Description: application/gzip

Bug#820857: java-package: Generated JDK package should have higher priority than existing openjdk packages

[Markus Koschany]

Hi,

Am 13.04.2016 um 11:43 schrieb Jan Henke:
> Free Software also means the freedom of choice. Yes, using free software is 
> preferably, but not always we can do that. This package's main purpose is to 
> enable non-free software to integrate as good as possible into Debian. You 
> have to acknowledge there is non-free software in the world and it is being 
> used, sometimes deliberately.

First of all I'm not aggressive just because I disagree with you. Even
if you may think so right now, I have just a different opinion what
should be the default in Debian. I understand that java-package is a
helper to package non-free software and there is nothing wrong with this
use case. I just don't think that we need to change a thing because it
is not hard to switch between different Java implementations at the moment.

> I opened this bug not just for myself, but to ask for something, that in my 
> opinion constitutes an improvement to this package and helps other people as 
> well. After I have been following the Java mailing lists for quite some time, 
> I am disappointed about this (in my opinion) aggressive replies to this bug.

Understood. And I beg to disagree with you in this case.

> I really appreciate Emanuel's suggestion, which would really solve the 
> problem for me and also keep the current default for everyone else. Having 
> the chance to make the new package the default simplifies the process for 
> many people. It keeps the current default and those, who will use the extra 
> parameter, would use the proprietary JDK as default anyway. So I fail to see 
> where that harms the free software. It just makes the life easier for some 
> people.

Yes, that's why we set the severity to wishlist and didn't mark the bug
as "wontfix". That means that we consider your bug report as an
improvement suggestion but someone needs to implement it first.

> Can we agree on adding Emanuel's proposal as an additional option and 
> otherwise refrain from ideological discussion about free vs non-free software 
> please?

Yes, I agree with Emmanuel's proposal and I never stated something
different. However it is my firm belief that using the right defaults is
important and it should come to no surprise if OpenJDK has a higher
priority than Oracle JDK in Debian. I also find the current way of
switching between JDKs not inconvenient. And that is all what I wrote in
my previous mails.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#820877: votca-csg-scripts: depends on unknown package perl5

[Andreas Beckmann]

Package: votca-csg-scripts
Version: 1.3.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

votca-csg-scripts/amd64 unsatisfiable Depends: perl5
votca-csg-scripts/i386 unsatisfiable Depends: perl5


Cheers,

Andreas

Bug#820878: gimmix: System tray hover doesn't show any information

[Thomas Versteeg]

Package: gimmix
Version: 0.5.7.1-5+b1
Severity: normal

Dear Maintainer,

When I hover my mouse on the Gimmix icon in the system tray (tested with tint2
and xfce4-panel), I get a empty image of a CD and a bar without any text or
information on it. I expected to see a progress bar and textfields to indicate
which song is playing and the progress of it.
I am willing to fix this issue myself, but I don't know where the repository of
gimmix is hosted (I am new to Debian development).

Cheers,
Thomas Versteeg



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

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

Versions of packages gimmix depends on:
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-5
ii  libcairo21.14.6-1+b1
ii  libcurl3-gnutls  7.47.0-1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libglade2-0  1:2.6.4-2
ii  libglib2.0-0 2.48.0-1
ii  libgtk2.0-0  2.24.30-1.1
ii  libmpd1  0.20.0-1.3
ii  libnxml0 0.18.3-6
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libtag1v5-vanilla1.9.1-2.4
ii  libtagc0 1.9.1-2.4
ii  libx11-6 2:1.6.3-1
ii  libxml2  2.9.3+dfsg1-1

gimmix recommends no packages.

gimmix suggests no packages.

-- no debconf information

Bug#820880: xscreensaver: version warning, but my apt-get upgrade was just today

[treaki]

Package: xscreensaver
Version: 5.30-1+deb8u1
Severity: important

Hi,

i am using debian stable (version 8 as of today) and since some days i have 
this very anoying warning (see screenshot).

Question one:

why the hack is there an algorythm of version warning included into 
xscreensaver?

Question two:

how dose this algorhytm work? Dose it just take my system time or what?

Question three:

why apt-get update; apt-get upgrade dosent fixes this very important bug

Question five:

what light is now shining on me when this message would appere during a 
presentation?


thanks in advance for the fix.

regards

treaki


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

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

Versions of packages xscreensaver depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u4
ii  libcairo21.14.0-2.1+deb8u1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u4
ii  libglade2-0  1:2.6.4-2
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libice6  2:1.0.9-1+b1
ii  libpam0g 1.1.8-3.1+deb8u1+b1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsm6   2:1.2.2-1+b1
ii  libx11-6 2:1.6.2-3
ii  libxext6 2:1.3.3-1
ii  libxi6   2:1.7.4-1+b2
ii  libxinerama1 2:1.1.3-1+b1
ii  libxml2  2.9.1+dfsg1-5+deb8u1
ii  libxmu6  2:1.1.2-1
ii  libxpm4  1:3.5.11-1+b1
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  libxt6   1:1.1.4-1+b1
ii  libxxf86vm1  1:1.1.3-1+b1
ii  xscreensaver-data5.30-1+deb8u1

Versions of packages xscreensaver recommends:
ii  libjpeg-progs 8d-1+deb7u1
ii  perl [perl5]  5.20.2-3+deb8u4
ii  wamerican [wordlist]  7.1-1
ii  wngerman [wordlist]   20131206-5

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]   49.0.2623.108-1~deb8u1
pn  fortune  
pn  gdm3 | kdm-gdmcompat 
ii  iceweasel [www-browser]  38.7.1esr-1~deb8u1
ii  konqueror [www-browser]  4:4.14.2-1
ii  links2 [www-browser] 2.8-2+b3
ii  lynx-cur [www-browser]   2.8.9dev1-2+deb8u1
pn  qcam | streamer  
ii  uzbl [www-browser]   0.0.0~git.20120514-1.1
ii  w3m [www-browser]0.5.3-19
pn  xdaliclock   
pn  xfishtank
ii  xscreensaver-gl  5.30-1+deb8u1

-- no debconf information

Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed

[Andreas Beckmann]

Package: r-cran-shiny
Version: 0.13.1+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

1m45.1s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpmbw__d', 
'apt-get', '-y', 'install', 'r-cran-shiny']
1m45.6s DUMP: 
  Reading package lists...
  Building dependency tree...
  Reading state information...
  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:
   r-cran-shiny : Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to 
be installed
  E: Unable to correct problems, you have held broken packages.


Cheers,

Andreas

Bug#820881: phpmyadmin: fails to upgrade from 'jessie': PHP Parse error: syntax error, unexpected 'mysqli_query' (T_STRING)

[Andreas Beckmann]

Package: phpmyadmin
Version: 4:4.6.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails.

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

  Setting up phpmyadmin (4:4.6.0-1) ...
  Installing new version of config file /etc/phpmyadmin/apache.conf ...
  Installing new version of config file /etc/phpmyadmin/config.inc.php ...
  Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
  dbconfig-common: writing config to /etc/dbconfig-common/phpmyadmin.conf
  Replacing config file /etc/dbconfig-common/phpmyadmin.conf with new version
  Replacing config file /etc/phpmyadmin/config-db.php with new version
  creating database backup in 
/var/cache/dbconfig-common/backups/phpmyadmin_4:4.2.12-2+deb8u1.2016-04-12-19.00.23.
  applying upgrade script for 4:4.2.12-2+deb8u1 -> 4:4.5.0.1-1.
  PHP Parse error:  syntax error, unexpected 'mysqli_query' (T_STRING) in 
/usr/share/dbconfig-common/scripts/phpmyadmin/upgrade/mysql/4:4.5.0.1-1 on line 
18
  error encountered processing 
/usr/share/dbconfig-common/scripts/phpmyadmin/upgrade/mysql/4:4.5.0.1-1:
  /usr/share/dbconfig-common/scripts/phpmyadmin/upgrade/mysql/4:4.5.0.1-1 
exited with non-zero status
  dbconfig-common: phpmyadmin configure: aborted.
  dbconfig-common: flushing administrative password
  dpkg: error processing package phpmyadmin (--configure):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for libc-bin (2.22-6) ...
  Processing triggers for systemd (229-4) ...
  Errors were encountered while processing:
   phpmyadmin


cheers,

Andreas


phpmyadmin_4:4.6.0-1.log.gz
Description: application/gzip

Bug#429432: 1152x768 can no longer be used on PowerBook, incorrect display [Rage Mobility M3, 4c46]

[Vincent Lefevre]

Control: tags -1 wontfix

Tagging again without -done since "Control:" pseudo-headers are
not taken into account with -done.

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

Bug#820882: sbuild: --extra-package= broken

[Brian May]

Package: sbuild
Version: 0.68.0-1
Severity: important

Hello,

According to the documentation:

   --extra-repository=spec
  Add  a  repository to the list of apt sources during the package
  build.  The repository specification is a line suitable  for  an
  apt   sources.list(5)   file.   For   instance,  you  might  use
  --extra-repository="deb   http://httpredir.debian.org/debian
  experimental main" to allow packages in the experimental distri‐
  bution to fulfill build-dependencies. Note that the build chroot
  must  already  trust the key of this repository or a key must be
  given with the --extra-repository-key flag. (see apt-secure(8))

However I can't see any evidence of this actually doing anything.

I can't see any temp respository being referenced by /etc/apt/sources.list or
/etc/apt/sources.list.d/* nor find any repository.

The command line I am using is:

/usr/bin/perl /usr/bin/sbuild --arch-all --dist=wheezy --nolog
ants_1.9.2+svn680.dfsg-4 --extra-package=libav-doc_11.6-1~deb7u1_all.deb
--extra-package=libavcodec-extra_11.6-1~deb7u1_all.deb
--extra-package=libav-tools_11.6-1~deb7u1_i386.deb
--extra-package=libav-dbg_11.6-1~deb7u1_i386.deb
--extra-package=libavutil54_11.6-1~deb7u1_i386.deb
--extra-package=libavcodec56_11.6-1~deb7u1_i386.deb
--extra-package=libavdevice55_11.6-1~deb7u1_i386.deb
--extra-package=libavformat56_11.6-1~deb7u1_i386.deb
--extra-package=libavfilter5_11.6-1~deb7u1_i386.deb
--extra-package=libswscale3_11.6-1~deb7u1_i386.deb
--extra-package=libavutil-dev_11.6-1~deb7u1_i386.deb
--extra-package=libavcodec-dev_11.6-1~deb7u1_i386.deb
--extra-package=libavdevice-dev_11.6-1~deb7u1_i386.deb
--extra-package=libavformat-dev_11.6-1~deb7u1_i386.deb
--extra-package=libavfilter-dev_11.6-1~deb7u1_i386.deb
--extra-package=libswscale-dev_11.6-1~deb7u1_i386.deb
--extra-package=libavresample-dev_11.6-1~deb7u1_i386.deb
--extra-package=libavresample2_11.6-1~deb7u1_i386.deb
--extra-package=libavcodec-extra-56_11.6-1~deb7u1_i386.deb

The log file of the sbuild has no references to this version of libav
(6:11.6-1~deb7u1).  Instead it is using the older version in wheezy,
6:0.8.17-2.

sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on prune.linuxpenguins.xyz

+==+
| ants 1.9.2+svn680.dfsg-4 (amd64)   13 Apr 2016 20:37 |
+==+

Package: ants
Version: 1.9.2+svn680.dfsg-4
Source Version: 1.9.2+svn680.dfsg-4
Distribution: wheezy
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64

I: NOTICE: Log filtering will replace 
'build/ants-hp9Plo/ants-1.9.2+svn680.dfsg' with '<>'
I: NOTICE: Log filtering will replace 'build/ants-hp9Plo' with '<>'
I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/wheezy-amd64-sbuild-c899c328-43d8-4c27-bd0f-31f5ba846db5'
 with '<>'

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

Hit http://localhost wheezy Release.gpg
Hit http://localhost wheezy Release
Hit http://localhost wheezy/main Sources
Hit http://localhost wheezy/main amd64 Packages
Hit http://localhost wheezy/main Translation-en
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
Building dependency tree...
Reading state information...
NOTICE: 'ants' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/pkg-exppsy/ants.git
Need to get 6505 kB of source archives.
Get:1 http://localhost/debian/ wheezy/main ants 1.9.2+svn680.dfsg-4 (dsc) [1586 
B]
Get:2 http://localhost/debian/ wheezy/main ants 1.9.2+svn680.dfsg-4 (tar) [6497 
kB]
Get:3 http://localhost/debian/ wheezy/main ants 1.9.2+svn680.dfsg-4 (diff) 
[6545 B]
Fetched 6505 kB in 5s (1227 kB/s)
Download complete and in download only mode

+--+
| Install build-essential  |
+--+


Setup apt archive
-

Merged Build-Depends: build-essential, fakeroot
Filtered Build-Depends: build-essential, fakeroot
dpkg-deb: building 

Bug#820843: tail'ing a file in a script session hangs

[Andreas Henriksson]

Control: tags -1 + upstream fixed-upstream
Control: forwarded -1 
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=b2bff0666101213d5ce9fc4166d8fc5b17581f57

Hello Simon Deziel.

On Tue, Apr 12, 2016 at 08:12:56PM -0400, Simon Deziel wrote:
> Package: util-linux
> Version: 2.27.1-6
> 
> Hello,
> 
> I noticed a regression after upgrading from 2.26.2 to 2.27.1. Here are
> the steps to reproduce:
> 
> 1) Start script session (same issue when script is saving to /dev/null)
> script # or: script /dev/null
> 2) Tail a file
> tailf /var/log/syslog
> 3) Press "Enter" 2 times
> 4) Notice the script process taking 100% CPU
> 
> This regression was introduced upstream by this commit:
> https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=54c6611d6f7b73609a5331f4d0bcf63c4af6429e

Thanks for your exemplary bug report. I mentioned it to upstream which
promptly answered that it's now fixed in
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=b2bff0666101213d5ce9fc4166d8fc5b17581f57

Please feel free to notify upstream directly in the future if you find
any similar issues.

Regards,
Andreas Henriksson

PS. Please note that tailf is deprecated. Use tail -f 

Bug#766794: Radare2 - new upstream version (0.10.2) available

[Max Kosmach]

Hi!

Radare2 0.10.2 is out.
Please update packages in debian.

--
With best wishes
Max

Bug#820883: dmeventd: dm-event.socket started too early preventing proper mount of /var

[François Scala]

Package: dmeventd
Version: 2:1.02.90-2.2
Severity: important

Dear Maintainer,

While working a on ZFS root Debian installation, I've encoutered a 
problem with dm-event.socket.
As it is loadeed too early, it create files in /var/run before the /var 
volume being mounted.


Therefore /var remain unmounted and it's contents (like /var/lib) 
unacessible.


Here is the opened files before the "zfs mount -a" command :

  COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
  systemd   1 root   27u  FIFO   0,16  0t0 49154 
/var/run/dmeventd-server
  systemd   1 root   28u  FIFO   0,16  0t0 49155 
/var/run/dmeventd-client


As a workarround, I've added the following line in dm-event.socket

  After=systemd-remount-fs.service


Regards

François.

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

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

Versions of packages dmeventd depends on:
ii  init-system-helpers   1.22
ii  libc6 2.19-18+deb8u4
ii  libdevmapper-event1.02.1  2:1.02.90-2.2
ii  libdevmapper1.02.12:1.02.90-2.2
ii  liblvm2cmd2.022.02.111-2.2

dmeventd recommends no packages.

dmeventd suggests no packages.

-- no debconf information

Bug#820884: Please update unetbootin to latest upstream version

[Amr Ibrahim]

Package: unetbootin
Version: 608-1

Please update unetbootin to latest upstream version.
https://github.com/unetbootin/unetbootin

Thanks,
Amr

Bug#820885: prosody-modules: please also include by default those modules, that are tagged as stable by upstream

[Daniel Scharon]

Package: prosody-modules
Version: 0.0~hg20150813.12ac88940fe3-2
Severity: wishlist

I really appreciate the current selection of modules, but I think it
should by
default be expanded with at least those modules, that are tagged as
'stable' by
upstream.

The current list can be seen here:
https://modules.prosody.im/stage_stable.html

Thank you and kind regards,
Dan





smime.p7s
Description: S/MIME cryptographic signature

Bug#816101: petsc: FTBFS on mipsel - broken openmpi breaks petsc build

[Drew Parsons]

reopen 816101
found 816101 3.6.3.dfsg2-4
thanks

A workaround for openmpi has now been applied (1.10.2-12+b1) enabling
petsc to build on mips64el (and mips).

But the petsc build still fails on mipsel.

The log does not reveal any failure mode.  The build completes
successfully.  The test for mipsel-linux-gnu-real-debug (i.e. for the
debug package) passes successfully.  

The failure happens during the test for mipsel-linux-gnu-real (the main
build version).  It passes the first test using 1 MPI process.  It
fails during the second test using 2 MPI processes. The test is ex19 in
petsc-3.6.3.dfsg2/src/snes/examples/tutorials.

I can reproduce the problem in a schroot on etler.debian.org.  I first
build the library (debian/rules build).  Then run the tests by hand:

$ cd ~/petsc/petsc-3.6.3.dfsg2/src/snes/examples/tutorials
$ PETSC_DIR=/home/dparsons/petsc/petsc-3.6.3.dfsg2 
PETSC_ARCH=mipsel-linux-gnu-real 
LD_LIBRARY_PATH=:/home/dparsons/petsc/petsc-3.6.3.dfsg2/mipsel-linux-gnu-real/lib
  make clean
$ PETSC_DIR=/home/dparsons/petsc/petsc-3.6.3.dfsg2 
PETSC_ARCH=mipsel-linux-gnu-real 
LD_LIBRARY_PATH=:/home/dparsons/petsc/petsc-3.6.3.dfsg2/mipsel-linux-gnu-real/lib
  make ex19
$ PETSC_DIR=/home/dparsons/petsc/petsc-3.6.3.dfsg2 
PETSC_ARCH=mipsel-linux-gnu-real 
LD_LIBRARY_PATH=:/home/dparsons/petsc/petsc-3.6.3.dfsg2/mipsel-linux-gnu-real/lib
  mpirun -n 1 ./ex19 -da_refine 3 -pc_type mg -ksp_type fgmres

This is the first test (1 process), which succeeds. The second test
with two processes simply uses -n 2:
$ PETSC_DIR=/home/dparsons/petsc/petsc-3.6.3.dfsg2 
PETSC_ARCH=mipsel-linux-gnu-real 
LD_LIBRARY_PATH=:/home/dparsons/petsc/petsc-3.6.3.dfsg2/mipsel-linux-gnu-real/lib
  mpirun -n 2 ./ex19 -da_refine 3 -pc_type mg -ksp_type fgmres

This test doesn't "fail" as such, it just never completes. It must be
caught in a deadlock.  I think the failure seen in the automated build
is a timeout. Apparently the buildd halts the build after 5 hours.

The strange thing is that this problem only happens for the normal real
build (with mipsel-linux-gnu-real).

The other three build permutations (real-debug, complex and 
complex-debug) run the same 2-processor test just fine.

Any ideas what to do next?  The openmpi bug (#818909) still has some
unfinished business with chrpath for mips architectures to remove the
workaround applied in 1.10.2-12. Could this generate a deadlock in one
petsc build but not the others?

Drew

Bug#820610: RM: libpgplot-perl [arm64 hurd-i386] -- ROM; unusable binary packages

[Andreas Beckmann]

On Sun, 10 Apr 2016 16:16:56 +0200 gregor herrmann 
wrote:
> Please remove the arm64 and hurd-i386 1:2.21-5 binary packages of
> libpgplot-perl from unstable.
> 
> I have no idea who built/uploaded them and for what reasons, but
> they don't work (dependency on perl 5.20).

https://buildd.debian.org/status/fetch.php?pkg=libpgplot-perl&arch=hurd-i386&ver=1%3A2.21-5&stamp=1409356434

In 2013, that hurd-i386 buildd had pgplot5/non-free installed !?!
I don't know where that arm64 build came from, though.
(btw, I did the 2.21-5+b1 binNMU for i386/amd64)


Andreas

Bug#820727: nmh: file /usr/share/man/man1/mhmail.1.gz (of link group mailx) doesn't exist

[Alexander Zangerl]

severity 820727 minor
thanks

On Mon, 11 Apr 2016 20:24:01 +0200, Jakub Wilk writes:
>I get these warnings when installing the package:
>
>update-alternatives: warning: skip creation of /usr/share/man/man1/mailx.1.gz b
>ecause associated file /usr/share/man/man1/mhmail.1.gz (of link group mailx) do
>esn't exist

thanks for the info; looks like i missed updating
the update-alternatives stanza when the mh manpages were adjusted
to use their most appropriate "mh" namespace
(ie. mhmail.1mh.gz not mhmail.1.gz).

i'll fix that within the next few days.

regards
az


-- 
Alexander Zangerl + GPG Key 0xB963BD5F + http://snafu.priv.at/
Q. why do you get when you cross an elephant and a grape?
A. sin(theta) Note: assumes |elephant|==|grape|==1


signature.asc
Description: Digital Signature

Bug#820886: virtualbox: Return od the virtualbox-fuse package

[Erez Geva]

Package: virtualbox
Version: 5.0.16-dfsg-2
Severity: wishlist
Tags: patch

Hi,

I saw that virtualbox-fuse was removed.

I downlaod the files from virtualbox forum.
http://forums.virtualbox.org/viewtopic.php?t=33355

I tried to build, but failed first.

So I patched the version build it and checked it with virtualbox version
5.0.16-dfsg-2.

I'd be nice if you could rebuild the virtualbox-fuse package using the patch
bellow.

Thanks
  Erez Geva



diff -u vdbuild vdbuild
--- vdbuild 2016-04-11 13:11:00.0 +0200
+++ vdbuild 2016-04-11 14:33:11.050898322 +0200
@@ -41,10 +41,7 @@
exit 1
 fi

-oldvboxhdd=""
-if [ -e "${incdir}/VBox/VBoxHDD-new.h" ]; then
-   oldvboxhdd="-DOLDVBOXHDD"
-elif ! [ -e "${incdir}/VBox/VBoxHDD.h" ]; then
+if ! [ -e "${incdir}/VBox/vd.h" ]; then
echo "Invalid include directory. Make sure that it has the VBox
directory inside."
exit 1
 fi
@@ -53,8 +50,9 @@
`pkg-config --cflags --libs fuse` \
-I"${incdir}" \
-Wl,-rpath,"${INSTALL_DIR}" \
-   -l:"${INSTALL_DIR}"/VBoxDD.so \
-   -Wall ${oldvboxhdd} ${CFLAGS}
+   "${INSTALL_DIR}"/VBoxDD.so \
+   "${INSTALL_DIR}"/VBoxDDU.so \
+   -Wall ${CFLAGS}

 if [ -z "${NOSTRIP}" ]; then
strip -sx "${outfile}"
diff -u vdfuse-v80.c vdfuse-v80.c
--- vdfuse-v80.c2016-04-11 13:11:00.0 +0200
+++ vdfuse-v80.c2016-04-11 16:58:28.604581333 +0200
@@ -111,13 +111,8 @@
 // no longer test this, I've decided to remove this old API code, but I have
left the abstraction in
 // I also used the ...testcase/tstVD.cpp as a coding template to work out how
to call the VD routines.

-// if you don't have VBoxHDD.h, run 'svn co
http://www.virtualbox.org/svn/vbox/trunk/include'
-// if your VirtualBox version is older than 2.1, add -DOLDVBOXHDD to your gcc
flags
-#ifdef OLDVBOXHDD // < v2.1
-#include 
-#else // >= v2.1
-#include 
-#endif
+// run 'svn co http://www.virtualbox.org/svn/vbox/trunk/include'
+#include 
 #define DISKread(o,b,s) VDRead (hdDisk,o,b,s);
 #define DISKwrite(o,b,s) VDWrite (hdDisk,o,b,s);
 #define DISKclose VDCloseAll(hdDisk)
@@ -127,13 +122,23 @@
if (RT_FAILURE(VDOpen(hdDisk,t , i, readonly ? VD_OPEN_FLAGS_READONLY :
VD_OPEN_FLAGS_NORMAL, NULL))) \
   usageAndExit("opening vbox image failed");

+static DECLCALLBACK(void) handleVDError(void *pvUser, int rc, RT_SRC_POS_DECL,
const char *pszFormat, va_list va)
+{
+vfprintf(stderr, pszFormat, va);
+fprintf(stderr, "Error code rc %u", rc);
+}
+
+static DECLCALLBACK(int) handleVDMessage(void *pvUser, const char *pszFormat,
va_list va)
+{
+vfprintf(stderr, pszFormat, va);
+return 0;
+}
+
 PVBOXHDD hdDisk;
 PVDINTERFACE pVDifs = NULL;
-VDINTERFACE  vdError;
-VDINTERFACEERROR vdErrorCallbacks = {
-   .cbSize = sizeof(VDINTERFACEERROR),
-   .enmInterface = VDINTERFACETYPE_ERROR,
-   .pfnError = vdErrorCallback };
+VDINTERFACEERROR vdInterfaceError = {
+   .pfnError = handleVDError,
+   .pfnMessage= handleVDMessage };

 // Partition table information

@@ -261,10 +266,10 @@
//
// *** Open the VDI, parse the MBR + EBRs and connect to the fuse service
***
//
-   if (RT_FAILURE(VDInterfaceAdd(&vdError, "VD Error", VDINTERFACETYPE_ERROR,
- &vdErrorCallbacks, NULL, &pVDifs)))
+   if (RT_FAILURE(VDInterfaceAdd(&vdInterfaceError.Core, "VD Error",
VDINTERFACETYPE_ERROR,
+ NULL, sizeof(VDINTERFACEERROR), &pVDifs)))
usageAndExit("invalid initialisation of VD interface");
-   if (RT_FAILURE(VDCreate(&vdError, &hdDisk)))
+   if (RT_FAILURE(VDCreate(pVDifs, VDTYPE_HDD, &hdDisk)))
  usageAndExit("invalid initialisation of VD interface");
DISKopen(diskType, imagefilename);




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

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

Versions of packages virtualbox depends on:
ii  adduser   3.114
ii  init-system-helpers   1.29
ii  libc6 2.22-5
ii  libcurl3-gnutls   7.47.0-1
ii  libgcc1   1:5.3.1-13
ii  libgsoap8 2.8.28-2
ii  libpng12-01.2.54-4+b1
ii  libpython2.7  2.7.11-7
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libssl1.0.2   1.0.2g-1
ii  libstdc++65.3.1-13
ii  libvncserver1 0.9.10+dfsg-3+b1
ii  libvpx3   1.5.0-2
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 

Bug#798777: laptop-mode-tools: "laptop-mode auto force" not run on resume from suspend with systemd

[Tomas Janousek]

Hi Ritesh,

On Thu, Apr 07, 2016 at 08:00:08PM +0530, Ritesh Raj Sarraf wrote:
> As you can see, when booted on battery, the correct mount settings were 
> applied.

Okay. I had to reboot today so I did some experiments and found a way to
reproduce this 100%:

1. comment out all lines in /lib/udev/rules.d/99-laptop-mode.rules to make
   sure udev doesn't interfere with the order of things

2. check /lib/udev/lmt-udev and make sure it doesn't contain the "systemctl -q
   is-active laptop-mode" check I sent you a few mails earlier

3. add this line to /lib/systemd/system/laptop-mode.service:
   ExecStartPre=/bin/bash -c "/lib/udev/lmt-udev force modules=runtime-pm; 
sleep 5"

4. reboot

Now you should see something like this:

# systemctl status laptop-mode.service
[...]
  Process: 2520 ExecStart=/usr/sbin/laptop_mode init auto (code=exited, 
status=0/SUCCESS)
  Process: 682 ExecStartPre=/bin/bash -c /lib/udev/lmt-udev force 
modules=runtime-pm; sleep 5 (code=exited, statu
[...]

# journalctl -b | grep '\[2520\]' | tail -1
dub 13 12:57:41 notes.lisk.in laptop_mode[2520]: enabled, not active [unchanged]

See, it says unchanged!

Another way to reproduce is simply to service laptop-mode stop (making sure
the udev rules are commented out) and then execute these commands manually:

# /usr/sbin/laptop_mode force modules=runtime_pm
# /usr/sbin/laptop_mode init auto

It will be easy to see that the second invocation does not change anything at
all, assuming that everything has been done already, but it has not since the
first invocation only run the runtime_pm module.

I hope it is clear now that the the "force modules=runtime_pm" invocation must
not happen before laptop-mode is started proper.

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

Bug#820879: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

Hi,

via this bug I learned (the hard way) that a

   Depends: ${js:Depends}

will be resolved into

   libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)

(for instance) in the final package.  I have no reason to assume that
the actual version that was available at package build time is the only
valid dependency for my package.  So it seems unadvisable to use
${js:Depends} depends at all to avoid continuous uploading of the
package (depending from 9 different libjs-* packages) if any of its
libjs-* was uploaded with a new version.

I wonder what the idea behind this resulution of the ${js:Depends}
would be since I have the feeling that this is not sensible in the
most practical cases.

Am I missing something?

Kind regards

  Andreas.

On Wed, Apr 13, 2016 at 12:33:41PM +0200, Andreas Beckmann wrote:
> Package: r-cran-shiny
> Version: 0.13.1+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package is no longer
> installable in sid:
> 
> 1m45.1s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpmbw__d', 
> 'apt-get', '-y', 'install', 'r-cran-shiny']
> 1m45.6s DUMP: 
>   Reading package lists...
>   Building dependency tree...
>   Reading state information...
>   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:
>r-cran-shiny : Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to 
> be installed
>   E: Unable to correct problems, you have held broken packages.
> 
> 
> Cheers,
> 
> Andreas
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#794941: Acknowledgement (squirrelmail: Installing on a debian 8.1 upgraded from 7 fails, works if installed on a native 8.1 or 8.0->8.1)

[Leonardo Boselli]

I found the problem: on upgrade of apache an old php5 module was retained 
an called together with new one, so the erratic working 9also wordpress 
was affected). so the bug is not of squirrelmail but rather of the apache 
upgrade process, that allow the cohesistence of incompatible modules.

Bug#820887: libpng-dev: Drop some of the packages in the Replaces field

[Laurent Bigonville]

Package: libpng-dev
Version: 1.6.21-2
Severity: normal

Hi,

The package contains the following Breaks, Replaces and Conflicts:

Replaces: libpng12-0-dev, libpng12-dev, libpng16-dev (<< 1.6.20-3), 
libpng16-devtools (<< 1.6.21-1), libpng2-dev, libpng3-dev
Conflicts: libpng12-0-dev, libpng12-dev, libpng2-dev, libpng3-dev
Breaks: libpng16-dev (<< 1.6.20-3), libpng16-devtools (<< 1.6.21-1)

IMHO, it makes no sense to have both for the same packages a Replaces
and a Conflits as the policy states:

 When one binary package declares a conflict with another using a
 Conflicts field, dpkg will refuse to allow them to be unpacked on the
 system at the same time.[0]

Could you please change the relations to:

Replaces: libpng16-dev (<< 1.6.20-3), libpng16-devtools (<< 1.6.21-1)
Conflicts: libpng12-0-dev, libpng12-dev, libpng2-dev, libpng3-dev
Breaks: libpng16-dev (<< 1.6.20-3), libpng16-devtools (<< 1.6.21-1)

Cheers,

Laurent Bigonville

[0] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

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

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

Bug#802224: Packaging node-source-map 0.5.2

[Julien Puydt]

Hi,

I pushed changes to the git repository for node-source-map, trying to 
push 0.5.2 in Debian.


There's a lintian complaint:

E: node-source-map source: source-is-missing 
bench/scalajs-runtime-sourcemap.js line length is 32684 characters (>512)


for which I don't know exactly what to do.

What do you think about it?

Snark on #debian-js

Bug#820886: virtualbox: Return od the virtualbox-fuse package

[Gianfranco Costamagna]

control: tags -1 moreinfo

Hi,

find . -name "vdfuse*"

find  . -name vdbuild


your patch is against files that aren't in the source tree.

How am I supposed to apply it?

please upstream the changes if you care about fuse package.


g.




Il Mercoledì 13 Aprile 2016 13:09, Erez Geva  ha scritto:
Package: virtualbox
Version: 5.0.16-dfsg-2
Severity: wishlist
Tags: patch

Hi,

I saw that virtualbox-fuse was removed.

I downlaod the files from virtualbox forum.
http://forums.virtualbox.org/viewtopic.php?t=33355

I tried to build, but failed first.

So I patched the version build it and checked it with virtualbox version
5.0.16-dfsg-2.

I'd be nice if you could rebuild the virtualbox-fuse package using the patch
bellow.

Thanks
  Erez Geva



diff -u vdbuild vdbuild
--- vdbuild 2016-04-11 13:11:00.0 +0200
+++ vdbuild 2016-04-11 14:33:11.050898322 +0200
@@ -41,10 +41,7 @@
exit 1
fi

-oldvboxhdd=""
-if [ -e "${incdir}/VBox/VBoxHDD-new.h" ]; then
-   oldvboxhdd="-DOLDVBOXHDD"
-elif ! [ -e "${incdir}/VBox/VBoxHDD.h" ]; then
+if ! [ -e "${incdir}/VBox/vd.h" ]; then
echo "Invalid include directory. Make sure that it has the VBox
directory inside."
exit 1
fi
@@ -53,8 +50,9 @@
`pkg-config --cflags --libs fuse` \
-I"${incdir}" \
-Wl,-rpath,"${INSTALL_DIR}" \
-   -l:"${INSTALL_DIR}"/VBoxDD.so \
-   -Wall ${oldvboxhdd} ${CFLAGS}
+   "${INSTALL_DIR}"/VBoxDD.so \
+   "${INSTALL_DIR}"/VBoxDDU.so \
+   -Wall ${CFLAGS}

if [ -z "${NOSTRIP}" ]; then
strip -sx "${outfile}"
diff -u vdfuse-v80.c vdfuse-v80.c
--- vdfuse-v80.c2016-04-11 13:11:00.0 +0200
+++ vdfuse-v80.c2016-04-11 16:58:28.604581333 +0200
@@ -111,13 +111,8 @@
// no longer test this, I've decided to remove this old API code, but I have
left the abstraction in
// I also used the ...testcase/tstVD.cpp as a coding template to work out how
to call the VD routines.

-// if you don't have VBoxHDD.h, run 'svn co
http://www.virtualbox.org/svn/vbox/trunk/include'
-// if your VirtualBox version is older than 2.1, add -DOLDVBOXHDD to your gcc
flags
-#ifdef OLDVBOXHDD // < v2.1
-#include 
-#else // >= v2.1
-#include 
-#endif
+// run 'svn co http://www.virtualbox.org/svn/vbox/trunk/include'
+#include 
#define DISKread(o,b,s) VDRead (hdDisk,o,b,s);
#define DISKwrite(o,b,s) VDWrite (hdDisk,o,b,s);
#define DISKclose VDCloseAll(hdDisk)
@@ -127,13 +122,23 @@
if (RT_FAILURE(VDOpen(hdDisk,t , i, readonly ? VD_OPEN_FLAGS_READONLY :
VD_OPEN_FLAGS_NORMAL, NULL))) \
   usageAndExit("opening vbox image failed");

+static DECLCALLBACK(void) handleVDError(void *pvUser, int rc, RT_SRC_POS_DECL,
const char *pszFormat, va_list va)
+{
+vfprintf(stderr, pszFormat, va);
+fprintf(stderr, "Error code rc %u", rc);
+}
+
+static DECLCALLBACK(int) handleVDMessage(void *pvUser, const char *pszFormat,
va_list va)
+{
+vfprintf(stderr, pszFormat, va);
+return 0;
+}
+
PVBOXHDD hdDisk;
PVDINTERFACE pVDifs = NULL;
-VDINTERFACE  vdError;
-VDINTERFACEERROR vdErrorCallbacks = {
-   .cbSize = sizeof(VDINTERFACEERROR),
-   .enmInterface = VDINTERFACETYPE_ERROR,
-   .pfnError = vdErrorCallback };
+VDINTERFACEERROR vdInterfaceError = {
+   .pfnError = handleVDError,
+   .pfnMessage= handleVDMessage };

// Partition table information

@@ -261,10 +266,10 @@
//
// *** Open the VDI, parse the MBR + EBRs and connect to the fuse service
***
//
-   if (RT_FAILURE(VDInterfaceAdd(&vdError, "VD Error", VDINTERFACETYPE_ERROR,
- &vdErrorCallbacks, NULL, &pVDifs)))
+   if (RT_FAILURE(VDInterfaceAdd(&vdInterfaceError.Core, "VD Error",
VDINTERFACETYPE_ERROR,
+ NULL, sizeof(VDINTERFACEERROR), &pVDifs)))
usageAndExit("invalid initialisation of VD interface");
-   if (RT_FAILURE(VDCreate(&vdError, &hdDisk)))
+   if (RT_FAILURE(VDCreate(pVDifs, VDTYPE_HDD, &hdDisk)))
  usageAndExit("invalid initialisation of VD interface");
DISKopen(diskType, imagefilename);




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

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

Versions of packages virtualbox depends on:
ii  adduser   3.114
ii  init-system-helpers   1.29
ii  libc6 2.22-5
ii  libcurl3-gnutls   7.47.0-1
ii  libgcc1   1:5.3.1-13
ii  libgsoap8 2.8.28-2
ii  libpng12-01.2.54-4+b1
ii  libpython2.7  2.7.11-7
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libssl1.0.2   1.0.2g-1
ii  libstdc++65.3.1

Bug#777791: Ball repository

[Andreas Tille]

Hi Alioth admins,

I've added Danny Edel a couple of days ago to the Debian Med team and
the page

   https://alioth.debian.org/project/admin/users.php?group_id=30063

lists him as "Junior Developer".  This has reliably worked all the time
but in this case there seems to be some problem.  Could you please have
a look?

Danny, please let not get used to some time consuming workarounds.  At
least I don't regard it productive to deal with different clones if
there is no need.  It just consumes time I currently definitly can't
spent on this.

Please either have a bit patience until alioth admins have sorted this
out or ask on Debian Med mailing list - which I would prefer in any
contact anyway - whether somebody else might volunteer to import the
patch and upload. (I've also kept the bug in CC.  Its always a good
idea to cumulate all relevant information about the issue there.)

Sorry, but I'm to busy at the moment and thanks a lot for your patience

 Andreas.

On Wed, Apr 13, 2016 at 12:49:40PM +0200, Danny Edel wrote:
> Hi Andreas,
> 
> I can still not write to /git/debian-med/ball.git, since I'm still not a
> member of scm_debian-med, although I am on the alioth webinterface. (my
> username on Debian is currently dannyedel-guest).
> 
> As a temporary solution, I've pushed my clone to github at
> https://github.com/dannyedel/pkg-debian-med-ball.git with the branch
> name "fix-debian-bug-91" so you can check if it works for you.
> 
> Cheers,
> 
> - Danny
> 




-- 
http://fam-tille.de

Bug#820888: cryptsetup: initramfs cryptroot zfs support

[François Scala]

Package: cryptsetup
Version: 2:1.6.6-5
Severity: normal

Dear Maintainer,

While working on a Debian installation based on ZFS root with LUKS 
encryption (see https://github.com/arcenik/debian-zfs-root) I've 
encountered some problem with the initramfs cryptroot script.


The LUKS is properly opened and the contained LVM volume properly detected.

It then try to detect the filesystem type from the root kernel parameter 
using blkid. But this fail because the root parameter value is not 
recognised by blkid


  root=ZFS=rpool/ROOT/debian-1

I think that ${cmdline_root} should be used for NEWROOT only if it begin 
with '/dev' or at least '/' and use '/dev/mapper/${cryptlvm}' if not.


Regards.

François.

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=ZFS=rpool/ROOT/debian-1 ro 
boot=zfs cryptops=source=/dev/sda2,target=cryptroot,lvm=vg_sys-lv_zroot


-- /etc/crypttab
# no crypttab

-- /etc/fstab
LABEL=BOOT/bootext4noatime01
LABEL=SWAPnoneswapdefaults00

-- lsmod
Module  Size  Used by
fuse   83350  0
btrfs 863629  0
xor21040  1 btrfs
raid6_pq   95238  1 btrfs
ufs73443  0
qnx4   13036  0
hfsplus   101391  0
hfs53845  0
minix  31387  0
ntfs  194605  0
vfat   17135  0
msdos  17046  0
fat61986  2 vfat,msdos
jfs   172859  0
xfs   779930  0
libcrc32c  12426  1 xfs
crc32c_generic 12656  0
ext4  473801  1
crc16  12343  1 ext4
mbcache17171  1 ext4
jbd2   82514  1 ext4
zfs  2614234  7
zunicode  328546  1 zfs
zcommon39960  1 zfs
znvpair58712  2 zfs,zcommon
spl69541  3 zfs,zcommon,znvpair
zavl   13071  1 zfs
dm_crypt   22595  1
dm_mod 89405  8 dm_crypt
xts12679  1
gf128mul   12970  1 xts
algif_skcipher 17349  0
af_alg 13034  1 algif_skcipher
nfsd  263032  2
auth_rpcgss51211  1 nfsd
oid_registry   12419  1 auth_rpcgss
nfs_acl12511  1 nfsd
nfs   188136  0
lockd  83389  2 nfs,nfsd
fscache45542  1 nfs
sunrpc237402  6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
ppdev  16782  0
snd_intel8x0   34948  0
joydev 17063  0
snd_ac97_codec118711  1 snd_intel8x0
pcspkr 12595  0
evdev  17445  3
snd_pcm88662  2 snd_ac97_codec,snd_intel8x0
serio_raw  12849  0
snd_timer  26614  1 snd_pcm
snd65244  4 
snd_ac97_codec,snd_intel8x0,snd_timer,snd_pcm

battery13356  0
soundcore  13026  1 snd
parport_pc 26300  0
parport35749  2 ppdev,parport_pc
processor  28221  0
video  18096  0
button 12944  0
ac 12715  0
ac97_bus   12510  1 snd_ac97_codec
thermal_sys27642  2 video,processor
i2c_piix4  20864  0
i2c_core   46012  1 i2c_piix4
autofs435529  2
squashfs   43856  1
loop   26605  3
aufs  199535  390
nls_utf8   12456  4
isofs  38965  1
hid_generic12393  0
usbhid 44460  0
hid   102264  2 hid_generic,usbhid
sd_mod 44356  3
crc_t10dif 12431  1 sd_mod
sg 29973  0
sr_mod 21903  1
cdrom  47424  1 sr_mod
crct10dif_generic  12581  1
crct10dif_common   12356  2 crct10dif_generic,crc_t10dif
ata_generic12490  0
ohci_pci   12808  0
crc32c_intel   21809  2
ata_piix   33592  1
ahci   4  2
libahci27158  1 ahci
psmouse99249  0
ohci_hcd   42982  1 ohci_pci
ehci_pci   12512  0
ehci_hcd   69837  1 ehci_pci
libata177508  4 ahci,libahci,ata_generic,ata_piix
scsi_mod  191405  4 sg,libata,sd_mod,sr_mod
usbcore   195468  5 ohci_hcd,ohci_pci,ehci_hcd,ehci_pci,usbhid
usb_common 12440  1 usbcore
e1000 122545  0


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

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

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:1

Bug#820889: logrotate configuration didn't signal HUP to service

[Reiner Keller]

Package: gearman-job-server
Version: 1.0.6-5
Section: misc

should be something like:

/var/log/gearman-job-server/*.log {
  daily
  rotate 4
  missingok
  compress
  postrotate
pid=$(pidof gearmand)
test -s $pid && kill -HUP $pid
  endscript
}

We are using multiple gearmand for different environments; single
gearmand can use instead:
  postrotate
pid=/var/run/gearman/gearmand.pid
test -s $pid && kill -HUP "$(cat $pid)"
  endscript

Bests


Reiner

Bug#820882: sbuild: --extra-package= broken

[Brian May]

Actually just realized this was partly my fault.

The debs being supplied via --extra-package were i386, but the chroot
being used was amd64. So the debs were being silently ignored.

Have to wonder about this, maybe an error should be displayed in this
situation?

If you disagree with displaying an error, feel free to close this bug
report.
-- 
Brian May 

Bug#820879: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[James Cowgill]

Hi,

On Wed, 2016-04-13 at 13:13 +0200, Andreas Tille wrote:
> via this bug I learned (the hard way) that a
> 
>    Depends: ${js:Depends}
> 
> will be resolved into
> 
>    libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)
> 
> (for instance) in the final package.  I have no reason to assume that
> the actual version that was available at package build time is the
> only
> valid dependency for my package.  So it seems unadvisable to use
> ${js:Depends} depends at all to avoid continuous uploading of the
> package (depending from 9 different libjs-* packages) if any of its
> libjs-* was uploaded with a new version.
> 
> I wonder what the idea behind this resulution of the ${js:Depends}
> would be since I have the feeling that this is not sensible in the
> most practical cases.
> 
> Am I missing something?

I think those dependencies come from dh_linktree and are placed in
${misc:Depends}, not ${js:Depends}.

dh_linktree(1) contains this:

Since symlink trees are created statically at build-time, they are not
very future-proof and have a risk to miss some files introduced by a
newer version of the package providing the file tree which is
duplicated. That's why the generated dependencies generally ensure that
the same upstream version be used at run-time than at build-time.

James

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

Bug#820890: linux-image-4.4.0-1-amd64: mount /dev/fd0 says: /dev/fd0 is not a valid block device

[Bernd Schumacher]

Package: src:linux
Version: 4.4.6-1
Severity: normal

Dear Maintainer,

after upgrading to the new kernel in my kvm I can not mount a floppy. 
I do not know what the last working kernel was, because I carelessly deleted 
the old kernel after upgrading.
But I have installed the kernel from jessie: linux-image-3.16.0-4-amd64 
3.16.7-ckt25-1 and when booting this kernel,
mounting floppy works again.

-- Package-specific info:
** Version:
Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160307 (Debian 5.3.1-11) ) #1 SMP Debian 4.4.6-1 (2016-03-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.0-1-amd64 
root=UUID=16ae2efa-8fbc-49d8-ab08-6cf3fc547d08 ro quiet

** Not tainted

** Kernel log:
[   34.120161]  0 90 4294900074
[   34.120163]  1 90 4294900074
[   34.120164]  2 90 4294900074
[   34.120166] 12 90 4294900074
[   34.120168] 1b 90 4294900074
[   34.120169] ff 90 4294900117
[   34.120171] last result at 4294900074
[   34.120172] last redo_fd_request at 4294900074
[   34.120176] 20 00 .
[   34.120205] status=f0
[   34.120207] fdc_busy=1
[   34.120212] do_floppy=main_command_interrupt [floppy]
[   34.120215] delayed work.function=a0138240 expires=16
[   34.120217] cont=a0140460
[   34.120219] current_req=88007adc1b90
[   34.120221] command_status=-1

[   34.120238] floppy0: floppy timeout called
[   34.120249] blk_update_request: I/O error, dev fd0, sector 0
[   34.120338] floppy: error -5 while reading block 0

[  844.504124] floppy driver state
[  844.504126] ---
[  844.504141] now=4295103422 last interrupt=4295102581 diff=841 last called 
handler=recal_interrupt [floppy]
[  844.504143] timeout_message=floppy start
[  844.504145] last output bytes:
[  844.504147]  0 90 4295102581
[  844.504149] 13 80 4295102581
[  844.504151]  0 90 4295102581
[  844.504153] 1a 90 4295102581
[  844.504154]  0 90 4295102581
[  844.504156]  3 80 4295102581
[  844.504158] c1 90 4295102581
[  844.504159] 11 90 4295102581
[  844.504161]  7 80 4295102581
[  844.504163]  8 80 4295102581
[  844.504165]  0 90 4295102581
[  844.504166] e6 80 4295102676
[  844.504168]  0 90 4295102676
[  844.504170]  0 90 4295102676
[  844.504171]  0 90 4295102676
[  844.504173]  1 90 4295102676
[  844.504175]  2 90 4295102676
[  844.504176] 12 90 4295102676
[  844.504178] 1b 90 4295102676
[  844.504180] ff 90 4295102718
[  844.504181] last result at 4295102581
[  844.504183] last redo_fd_request at 4295102581
[  844.504187] 20 00 .
[  844.504215] status=f0
[  844.504217] fdc_busy=1
[  844.504223] do_floppy=main_command_interrupt [floppy]
[  844.504225] delayed work.function=a0138240 expires=21
[  844.504227] cont=a0140460
[  844.504229] current_req=88007adc18b0
[  844.504231] command_status=-1

[  844.504248] floppy0: floppy timeout called
[  844.504258] blk_update_request: I/O error, dev fd0, sector 0
[  844.504350] floppy: error -5 while reading block 0

[  847.512122] floppy driver state
[  847.512124] ---
[  847.512138] now=4295104174 last interrupt=4295103422 diff=752 last called 
handler=recal_interrupt [floppy]
[  847.512140] timeout_message=floppy start
[  847.512142] last output bytes:
[  847.512144]  0 90 4295103422
[  847.512146] 13 80 4295103422
[  847.512148]  0 90 4295103422
[  847.512150] 1a 90 4295103422
[  847.512151]  0 90 4295103422
[  847.512153]  3 80 4295103422
[  847.512155] c1 90 4295103422
[  847.512156] 11 90 4295103422
[  847.512158]  7 80 4295103422
[  847.512160]  8 80 4295103422
[  847.512161]  0 90 4295103422
[  847.512163] e6 80 4295103422
[  847.512165]  0 90 4295103422
[  847.512167]  0 90 4295103422
[  847.512168]  0 90 4295103422
[  847.512170]  1 90 4295103422
[  847.512172]  2 90 4295103422
[  847.512173] 12 90 4295103422
[  847.512175] 1b 90 4295103422
[  847.512177] ff 90 4295103459
[  847.512178] last result at 4295103422
[  847.512180] last redo_fd_request at 4295103422
[  847.512200] 20 00 .
[  847.512228] status=f0
[  847.512230] fdc_busy=1
[  847.512236] do_floppy=main_command_interrupt [floppy]
[  847.512238] delayed work.function=a0138240 expires=10
[  847.512240] cont=a0140460
[  847.512242] current_req=88007adc18b0
[  847.512244] command_status=-1

[  847.512261] floppy0: floppy timeout called
[  847.512272] blk_update_request: I/O error, dev fd0, sector 0
[  847.512357] floppy: error -5 while reading block 0

** Model information
sys_vendor: Bochs
product_name: Bochs
product_version: 
chassis_vendor: Bochs
chassis_version: 
bios_vendor: Bochs
bios_version: Bochs

** Loaded modules:
snd_hda_codec_generic
hid_generic
ppdev
snd_hda_intel
cirrus
pcspkr
snd_hda_codec
joydev
evdev
snd_hda_core
serio_raw
ttm
snd_hwdep
virtio_console
virtio_balloon
drm_kms_helper
snd_pcm
snd_timer
snd
soundcore
drm
i2c_piix4
sg
acpi_cpufreq
usbhid
8250_fintek
parport_pc
h

Bug#820891: wrong servers for dns=dnsmasq and VPN

[Matus UHLAR - fantomas]

Package: network-manager
Version: 0.9.10.0-7

when using "dns=dnsmasq" with VPN connection, the dnsmasq is pointed to
VPN-provided DNS servers VPN-provided domain and reverse IPs, even if all
traffic is directed to VPN (edited):

environment in if-up.d scripts:

VPN_IP4_ADDRESS_0=10.b.c.d/32 ga.te.wa.y
VPN_IP4_DOMAINS=vpn.domain
VPN_IP4_NAMESERVERS=10.x.x.x 10.y.y.y
VPN_IP4_NUM_ADDRESSES=1
VPN_IP4_NUM_ROUTES=0
VPN_IP_IFACE=vpn0

dnsmasq configuration:

server=/vpn.domain/10.x.x.x
server=/10.in-addr.arpa/10.x.x.x
server=/vpn.domain/10.y.y.y
server=/10.in-addr.arpa/10.y.y.y
server=192.168.66.1

solution:
when all traffic is routed to VPN connection (VPN_IP4_NUM_ROUTES=0), all DNS
should be pointed to VPN nameservers, since original DNS servers may not be
reachable through the VPN connection:

server=10.x.x.x
server=10.y.y.y

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]

Bug#820889: Acknowledgement (logrotate configuration didn't signal HUP to service)

[Reiner Keller]

ah, sorry, small typo; in case for multiple gearmand processes it must be

pid=$(pidof gearmand)
test -z "$pid" && kill -HUP $pid

Bug#802224: Packaging node-source-map 0.5.2

[Leo Iannacone]

Hi Julien,

thanks to taking over this.

Is it really needed for the build or is just a test?

In any case, you should remove it from the orig, and create a dsfg version
of the archive.

Looks like realted to https://github.com/scala-js/scala-js btw..

Let me know!
L.

-- 
Ubuntu Member - http://launchpad.net/~l3on
Home Page - http://leoiannacone.com
GPG Key Id - 0xD282FC25

Bug#798777: laptop-mode-tools: "laptop-mode auto force" not run on resume from suspend with systemd

[Ritesh Raj Sarraf]

Package: laptop-mode-tools
Followup-For: Bug #798777


Hello Tomas,

Here's the steps I followed. These following commands logs are while the
machine was on AC.

First, I stopped laptop-mode-tools. Then I ran the command as you asked.
Since, at this time, the machine is on AC, it reports accordingly.


rrs@chutzpah:~$ journalctl -f
-- Logs begin at Sat 2015-07-11 23:49:25 IST. --
Apr 13 17:07:14 chutzpah su[1731]: pam_unix(su:session): session opened for 
user rrs by (uid=0)
Apr 13 17:07:14 chutzpah systemd-logind[3265]: New session c23 of user rrs.
Apr 13 17:07:14 chutzpah systemd[1]: Started Session c23 of user rrs.
Apr 13 17:07:14 chutzpah laptop_mode[1580]: Cannot find device "eth1"
Apr 13 17:07:14 chutzpah su[1731]: pam_unix(su:session): session closed for 
user rrs
Apr 13 17:07:14 chutzpah systemd-logind[3265]: Removed session c23.
Apr 13 17:07:14 chutzpah kernel: NMI watchdog: enabled on all CPUs, permanently 
consumes one hw-PMU counter.
Apr 13 17:07:14 chutzpah systemd[1]: Stopped Laptop Mode Tools.
Apr 13 17:07:14 chutzpah sudo[1279]: pam_unix(sudo:session): session closed for 
user root
Apr 13 17:07:14 chutzpah polkitd(authority=local)[3330]: Unregistered 
Authentication Agent for unix-process:1574:5619847 (system bus name :1.187, 
object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_IN) 
(disconnected from bus)
Apr 13 17:07:44 chutzpah laptop-mode[2617]: You do not have enough privileges 
to enable laptop_mode.
Apr 13 17:07:49 chutzpah sudo[2664]:  rrs : TTY=pts/3 ; PWD=/home/rrs ; 
USER=root ; COMMAND=/usr/sbin/laptop_mode force modules=runtime_pm
Apr 13 17:07:49 chutzpah sudo[2664]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
Apr 13 17:07:49 chutzpah laptop-mode[2709]: Laptop mode
Apr 13 17:07:49 chutzpah laptop-mode[2710]: enabled, not active
Apr 13 17:07:49 chutzpah sudo[2664]: pam_unix(sudo:session): session closed for 
user root
Apr 13 17:08:05 chutzpah sudo[2750]:  rrs : TTY=pts/3 ; PWD=/home/rrs ; 
USER=root ; COMMAND=/usr/sbin/laptop_mode init auto
Apr 13 17:08:05 chutzpah sudo[2750]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
Apr 13 17:08:05 chutzpah laptop-mode[2795]: enabled, not active [unchanged]
Apr 13 17:08:05 chutzpah sudo[2750]: pam_unix(sudo:session): session closed for 
user root
Apr 13 17:08:23 chutzpah sudo[2984]:  rrs : TTY=pts/3 ; PWD=/home/rrs ; 
USER=root ; COMMAND=/usr/bin/vi /lib/udev/rules.d/99-laptop-mode.rules
Apr 13 17:08:23 chutzpah sudo[2984]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
Apr 13 17:08:23 chutzpah systemd[1]: Starting Laptop Mode Tools - Battery 
Polling Service...
Apr 13 17:08:23 chutzpah systemd[1]: Starting Laptop Mode Tools...
Apr 13 17:08:23 chutzpah systemd[1]: Started Laptop Mode Tools - Battery 
Polling Service.
Apr 13 17:08:23 chutzpah laptop-mode[3036]: enabled, not active [unchanged]
Apr 13 17:08:23 chutzpah laptop_mode[2989]: enabled, not active [unchanged]
Apr 13 17:08:23 chutzpah systemd[1]: Started Laptop Mode Tools.
Apr 13 17:08:29 chutzpah sudo[2984]: pam_unix(sudo:session): session closed for 
user root
Apr 13 17:08:30 chutzpah sudo[3101]:  rrs : TTY=pts/3 ; PWD=/home/rrs ; 
USER=root ; COMMAND=/bin/systemctl daemon-reload
Apr 13 17:08:30 chutzpah sudo[3101]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
Apr 13 17:08:30 chutzpah polkitd(authority=local)[3330]: Registered 
Authentication Agent for unix-process:3109:5627497 (system bus name :1.190 
[/usr/bin/pkttyagent --notify-fd 4 --fallback], object path 
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_IN)
Apr 13 17:08:30 chutzpah systemd[1]: Reloading.
Apr 13 17:08:31 chutzpah systemd[1]: apt-daily.timer: Adding 9h 30min 8.896521s 
random time.
Apr 13 17:08:31 chutzpah sudo[3101]: pam_unix(sudo:session): session closed for 
user root
Apr 13 17:08:31 chutzpah polkitd(authority=local)[3330]: Unregistered 
Authentication Agent for unix-process:3109:5627497 (system bus name :1.190, 
object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_IN) 
(disconnected from bus)





At this point, I am now on BATT

Apr 13 17:08:43 chutzpah pulseaudio[4029]: [pulseaudio] sink-input.c: Failed to 
create sink input: sink is suspended.


Now, I ran the same commands. As you can see, it noticed the change and
activated it.

The follow-up invocation (i.e. "init auto") reported that the state (of
the machine) has not changed since the last invocation. Hence, it
reports "enabled, active [unchanged]".



Apr 13 17:08:55 chutzpah sudo[4886]:  rrs : TTY=pts/3 ; PWD=/home/rrs ; 
USER=root ; COMMAND=/usr/sbin/laptop_mode force modules=runtime_pm
Apr 13 17:08:55 chutzpah sudo[4886]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
Apr 13 17:08:55 chutzpah laptop-mode[4938]: Laptop mode
Apr 13 17:08:55 chutzpah laptop-mode[4939]: enabled, active
Apr 13 17:08:55 chutzpah sudo[4886]: pam_unix(sudo:session): session closed for 
user root
Apr 13 17:09:

Bug#820666: [Pkg-php-pecl] Bug#820666: Bug#820666: php5-redis: Segfault on pear upgrade-all with php5-redis installed

[Ondřej Surý]

If you want somebody to help you, you should at least put some effort
into it...

https://bugs.php.net/bugs-generating-backtrace.php

And don't forget to install php5-dbg first, so you have the symbols.

And if you are unwilling to help to debug this issue, I am sorry I will
not able to help you.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Wed, Apr 13, 2016, at 10:58, Prunk-Éger Edgár wrote:
> I'm sorry, I'm not sure how to create the backtrace.
> 
> Edgar
> 
> -- 
> 
> 
> On 2016-04-11 16:39, Ondřej Surý wrote:
> > Control: severity -1 normal
> > Control: tags -1 +moreinfo
> >
> > Please install appropriate -dbg packages and provide workable backtrace
> > for the failing command.
> >
> > Also please don't abuse bug severities. This is an important bug at
> > most, but most likely normal as it's not "a bug which has a major effect
> > on the usability of a package, without rendering it completely unusable
> > to everyone", so marking it as such.
> >
> > Cheers,
> >
> 
> ___
> Pkg-php-pecl mailing list
> pkg-php-p...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-pecl

Bug#789815: Accepted libpng 1.2.54-5 (source) into unstable

[Rene Engelhard]

reopen 789815
thanks

Hi,

On Wed, Apr 13, 2016 at 10:42:31AM +, Gianfranco Costamagna wrote:
> Description:
>  libpng12-0 - PNG library - runtime
>  libpng12-0-udeb - PNG library - minimal runtime library (udeb)
>  libpng12-dev - PNG library - development
>  libpng3- PNG library - runtime
   ^^
> Closes: 789815 820836
> Changes:
>  libpng (1.2.54-5) unstable; urgency=medium
>  .
>* Team upload.
>* Stop providing libpng-dev and libpng3 (Closes: #789815, #820836)

Sure?

And 
https://buildd.debian.org/status/fetch.php?pkg=libpng&arch=i386&ver=1.2.54-5&stamp=1460545019
 also shows a libpng3 built:


libpng3_1.2.54-5_i386.deb
─

 new debian package, version 2.0.
 size 976 bytes: control archive=484 bytes.
 527 bytes,17 lines  control  
 Package: libpng3
 Source: libpng
 Version: 1.2.54-5
 Architecture: i386
 Maintainer: Anibal Monsalve Salazar 
 Installed-Size: 9
 Depends: libpng12-0 (>= 1.2.5.0-2)
 Section: oldlibs
 Priority: optional
 Multi-Arch: same
 Homepage: http://libpng.org/pub/png/libpng.html
 Description: PNG library - runtime
  libpng is a library implementing an interface for reading and writing
  PNG (Portable Network Graphics) format files.
  .
  This package is superseded by libpng12-0, and is provided only for
  transitional purposes.

drwxr-xr-x root/root 0 2016-04-13 10:56 ./
drwxr-xr-x root/root 0 2016-04-13 10:56 ./usr/
drwxr-xr-x root/root 0 2016-04-13 10:56 ./usr/lib/
drwxr-xr-x root/root 0 2016-04-13 10:56 ./usr/lib/i386-linux-gnu/
lrwxrwxrwx root/root 0 2016-04-13 10:56 
./usr/lib/i386-linux-gnu/libpng.so.3 -> /lib/i386-linux-gnu/libpng12.so.0
drwxr-xr-x root/root 0 2016-04-13 10:56 ./usr/share/
drwxr-xr-x root/root 0 2016-04-13 10:56 ./usr/share/doc/
lrwxrwxrwx root/root 0 2016-04-13 10:56 ./usr/share/doc/libpng3 -> 
libpng12-0

Regards,

Rene

Bug#820892: use SIGINT when disconnecting VPN

[Matus UHLAR - fantomas]

Package: network-manager-openconnect
Version: 0.9.10.0-1

when disconnecting VPN, openconnect is killed with TERM signal:

# strace -p 15887
Process 15887 attached
select(9, [4 7 8], [], [7], {13, 244815}) = ? ERESTARTNOHAND (To be
restarted if no handler)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=15873, si_uid=0} ---
+++ killed by SIGTERM +++

that causes the session on the server to hang:

   SIGINT performs a clean shutdown by logging the  session  off,  discon‐
  necting from the gateway, and running the vpnc-script to restore
  the network configuration.

   SIGTERM
  exits immediately without logging off or running vpnc-script.

Please, use SIGINT for disconnecting.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler

Bug#802224: Packaging node-source-map 0.5.2

[Julien Puydt]

Hi,

On 13/04/2016 13:43, Leo Iannacone wrote:

Hi Julien,

thanks to taking over this.

Is it really needed for the build or is just a test?

In any case, you should remove it from the orig, and create a dsfg
version of the archive.

Looks like realted to https://github.com/scala-js/scala-js btw..

Let me know!
L.



Well, I made more tests, and my package just isn't worth anything :-(

I'll have to dig deeper :-/

Sorry for the noise,

Snark on #debian-js

Bug#815977: closed by Ben Hutchings (Re: Bug#815977: kernel-image-4.4.0-1-sparc64-di: Please add sunvnet and sunvdc for d-i)

[John Paul Adrian Glaubitz]

On 04/11/2016 01:32 AM, Ben Hutchings wrote:
> The attached patch might fix that, though the correct fix would
> presumably be to merge the two implementations.

Thanks a lot for the explanation and the patch. I will test the
patch and then we can maybe decide if we include it as a work
around.

I have also notified upstream and Dave Miller is now looking
at a proper fix.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Bug#820893: Error in package description

[Christian Hofstede]

Package: monitoring-plugins-standard
Version: 2.1.1-1

In the package description, it says, that "check_linux_raid" is 
contained in this package.
This has been removed on Fri, 18 May 2012 according to the changelog and 
is not part
of the package anymore. 
https://packages.debian.org/jessie/monitoring-plugins-standard

Here is a transcript:

Plugins for nagios compatible monitoring systems like Naemon and Icinga. 
It contains the following plugins:


 check_bgpstate, check_breeze, check_dbi, check_dig, check_disk_smb,
 check_dns, check_flexlm, check_fping, check_game,
 check_hpjd, check_ifoperstatus, check_ifstatus, check_ldap,
 check_ldaps, check_linux_raid, check_mailq, check_mysql,
 check_mysql_query, check_oracle, check_pgsql, check_radius,
 check_rpc, check_snmp, check_wave


I suggest that the package description is corrected.

I am using Debian GNU/Linux 8.4, Kernel 3.16.0-4.

Bug#820879: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

Hi James,

On Wed, Apr 13, 2016 at 12:28:58PM +0100, James Cowgill wrote:
> On Wed, 2016-04-13 at 13:13 +0200, Andreas Tille wrote:
> > via this bug I learned (the hard way) that a
> > 
> >    Depends: ${js:Depends}
> > 
> > will be resolved into
> > 
> >    libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)
> > 
> > (for instance) in the final package.  I have no reason to assume that
> > the actual version that was available at package build time is the
> > only
> > valid dependency for my package.  So it seems unadvisable to use
> > ${js:Depends} depends at all to avoid continuous uploading of the
> > package (depending from 9 different libjs-* packages) if any of its
> > libjs-* was uploaded with a new version.
> > 
> > I wonder what the idea behind this resulution of the ${js:Depends}
> > would be since I have the feeling that this is not sensible in the
> > most practical cases.
> > 
> > Am I missing something?
> 
> I think those dependencies come from dh_linktree and are placed in
> ${misc:Depends}, not ${js:Depends}.
> 
> dh_linktree(1) contains this:
> 
> Since symlink trees are created statically at build-time, they are not
> very future-proof and have a risk to miss some files introduced by a
> newer version of the package providing the file tree which is
> duplicated. That's why the generated dependencies generally ensure that
> the same upstream version be used at run-time than at build-time.

Ahhh, good hint.  So the solution to my problem would rather be to
drop dh_linktree? (Raphael in CC whether I might have missed something).

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#689068: Still not fixed?

[Riot]

Why is this still not fixed?  When building the same packages for 64bit or
32bit, I am having to remove and reinstall libxi-dev between each build,
which is ridiculous.

Bug#798777: laptop-mode-tools: "laptop-mode auto force" not run on resume from suspend with systemd

[Ritesh Raj Sarraf]

Package: laptop-mode-tools
Followup-For: Bug #798777

Hello Tomas,

And here's the logs/results based on a reboot.


The reboot was done while on BATT.


असतो मा सद्गमय  From untruth to truth
तमसो मा ज्योतिर्गमय From darkness to light
मृत्योर् मा अमृतं गमय   From death to immortality

17:41 ♒♒♒   ☺
rrs@chutzpah:~$ cat /proc/sys/vm/laptop_mode 
0
17:41 ♒♒♒   ☺
rrs@chutzpah:~$ uptime
 17:41:14 up 1 min,  1 user,  load average: 3.39, 1.35, 0.50
17:41 ♒♒♒   ☺


[rrs] As you can see above, it is a fresh boot. And because
laptop-mode-tools was disabled completely,  the kernel's state is set
appropriate.


rrs@chutzpah:~$ cat /lib/udev/rules.d/99-laptop-mode.rules 
#ACTION=="change", SUBSYSTEM=="power_supply", 
ENV{POWER_SUPPLY_NAME}=="|AC|ACAD", RUN+="lmt-udev auto"
#ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto"
#ACTION=="add|remove", SUBSYSTEM=="usb", RUN+="lmt-udev force 
modules=runtime-pm devices=%k"
17:41 ♒♒♒   ☺
rrs@chutzpah:~$ acpi
Battery 0: Discharging, 83%, 02:32:09 remaining
17:41 ♒♒♒   ☺


As you had said, I disabled udev invocation completely.



rrs@chutzpah:~$ sudo /usr/sbin/laptop_mode force modules=runtime-pm
[sudo] password for rrs: 
Laptop mode 
enabled, active
17:42 ♒♒♒   ☺


And the above is the first invocation and it sensed being on battery.
Thus enabled and activated it.

rrs@chutzpah:~$ sudo /usr/sbin/laptop_mode init auto
enabled, active [unchanged]
17:42 ♒♒♒   ☺

This second invocation, which would be the usual invocation through
systed (if the service was enabled), sensed the state and because
nothing needed a change, it just reported it.


rrs@chutzpah:~$ sudo systemctl status laptop-mode
● laptop-mode.service - Laptop Mode Tools
   Loaded: loaded (/lib/systemd/system/laptop-mode.service; disabled; vendor 
preset: enabled)
   Active: inactive (dead)
 Docs: man:laptop_mode(8)
   man:laptop-mode.conf(8)
   http://github.com/rickysarraf/laptop-mode-tools
17:43 ♒♒♒☹  => 3  

rrs@chutzpah:~$ sudo systemctl status laptop-mode.timer
● laptop-mode.timer - Runs Laptop Mode Tools - Polling Service, every 150 
seconds
   Loaded: loaded (/lib/systemd/system/laptop-mode.timer; disabled; vendor 
preset: enabled)
   Active: inactive (dead)
17:43 ♒♒♒☹  => 3  

rrs@chutzpah:~$ sudo systemctl status lmt-poll.service 
● lmt-poll.service - Laptop Mode Tools - Battery Polling Service
   Loaded: loaded (/lib/systemd/system/lmt-poll.service; disabled; vendor 
preset: enabled)
   Active: inactive (dead)
 Docs: man:laptop_mode(8)
   man:laptop-mode.conf(8)
   http://github.com/rickysarraf/laptop-mode-tools
17:43 ♒♒♒☹  => 3  


All 3 services were disabled during the manual invocation



I think I've found a bug, which might be what you have reported.

rrs@chutzpah:~$ sudo /usr/sbin/laptop_mode init auto
enabled, active [unchanged]
17:51 ♒♒♒   ☺

rrs@chutzpah:~$ cat /proc/sys/vm/laptop_mode 
0
17:51 ♒♒♒   ☺

At this stage, this should be reported as non-zero.

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

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

Versions of packages laptop-mode-tools depends on:
ii  init-system-helpers  1.29
ii  lsb-base 9.20160110
ii  psmisc   22.21-2.1+b1
ii  util-linux   2.27.1-6

Versions of packages laptop-mode-tools recommends:
ii  ethtool 1:4.5-1
ii  hdparm  9.48+ds-1
ii  net-tools   1.60+git20150829.73cef8a-2
ii  python-qt4  4.11.4+dfsg-1+b3
ii  sdparm  1.08-1
ii  udev229-4
ii  wireless-tools  30~pre9-9

Versions of packages laptop-mode-tools suggests:
pn  acpid | apmd | pbbuttonsd | pmud  

-- Configuration Files:
/etc/laptop-mode/conf.d/ac97-powersave.conf changed [not included]
/etc/laptop-mode/conf.d/cpufreq.conf changed [not included]
/etc/laptop-mode/conf.d/dpms-standby.conf changed [not included]
/etc/laptop-mode/conf.d/eee-superhe.conf changed [not included]
/etc/laptop-mode/conf.d/ethernet.conf changed [not included]
/etc/laptop-mode/conf.d/exec-commands.conf changed [not included]
/etc/laptop-mode/conf.d/hal-polling.conf changed [not included]
/etc/laptop-mode/conf.d/intel-hda-powersave.conf changed [not included]
/etc/laptop-mode/conf.d/intel-sata-powermgmt.conf changed [not included]
/etc/laptop-mode/conf.d/intel_pstate.conf changed [not included]
/etc/laptop-mode/conf.d/nmi-watchdog.conf changed [not included]
/etc/laptop-mode/conf.d/pcie-aspm.conf changed [not included]
/etc/laptop-mode/conf.d/radeon-dpm.conf changed [not included]
/etc/laptop-mode/conf.d/sched-mc-power-savings.conf changed [not included]
/etc/laptop-mode/conf.d/sched-smt-powe

Bug#820610: RM: libpgplot-perl [arm64 hurd-i386] -- ROM; unusable binary packages

[gregor herrmann]

On Wed, 13 Apr 2016 13:03:55 +0200, Andreas Beckmann wrote:

> On Sun, 10 Apr 2016 16:16:56 +0200 gregor herrmann 
> wrote:
> > Please remove the arm64 and hurd-i386 1:2.21-5 binary packages of
> > libpgplot-perl from unstable.
> > I have no idea who built/uploaded them and for what reasons, but
> > they don't work (dependency on perl 5.20).
> https://buildd.debian.org/status/fetch.php?pkg=libpgplot-perl&arch=hurd-i386&ver=1%3A2.21-5&stamp=1409356434
> In 2013, that hurd-i386 buildd had pgplot5/non-free installed !?!

Fascinating :)

> I don't know where that arm64 build came from, though.
> (btw, I did the 2.21-5+b1 binNMU for i386/amd64)

I know (saw it just a few days ago) but that never made it to testing
because of (the cruft and) #808331.

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #97:  Small animal kamikaze attack on power supplies 

Bug#820610: RM: libpgplot-perl [arm64 hurd-i386] -- ROM; unusable binary packages

[Mattia Rizzolo]

On Wed, Apr 13, 2016 at 01:03:55PM +0200, Andreas Beckmann wrote:
> I don't know where that arm64 build came from, though.

With a very much naive approach at projectb:

projectb=> select * from uid where id = (select uid from fingerprint where id = 
(select sig_fpr from binaries where package = 'libpgplot-perl' and architecture 
= (select id from architecture where arch_string='arm64')));
 id  |  uid   |  name  |created|   modified 
   
-+++---+---
 729 | wookey | Wookey | 2009-11-24 22:27:32.146952+00 | 2009-11-24 
22:27:32.146952+00
(1 row)

tbh, I'd love to know if there is a more straightforward way to have
this information...

-- 
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#820894: ocserv: RADIUS support not included

[Tony Zhou]

Package: ocserv
Version: 0.11.1-1
Severity: normal

Dear Maintainer,

It seems that RADIUS support is not included in the current release
(0.11.1-1) of ocserv. When starting
ocserv with configuration that uses radius for authentication, it gives
the following error:

tony@vpn:~$ sudo ocserv -f -c /etc/ocserv/ocserv.conf
Unknown or unsupported auth method:
radius[config=/etc/radcli/radiusclient.conf]

Also, it seems that libradcli4 dependency has been removed. Please
consider re-include radius support.

Thanks,
TZ

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

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

Versions of packages ocserv depends on:
ii dbus 1.10.8-1
ii init-system-helpers 1.29
ii libc6 2.22-5
ii libev4 1:4.22-1
ii libgnutls30 3.4.10-4
ii libgssapi-krb5-2 1.13.2+dfsg-5
ii libhttp-parser2.1 2.1-2
ii liblz4-1 0.0~r131-2
ii libnettle6 3.2-1
ii libnl-3-200 3.2.27-1
ii libnl-route-3-200 3.2.27-1
ii liboath0 2.6.1-1
ii libopts25 1:5.18.7-3
ii libpam0g 1.1.8-3.2
ii libpcl1 1.6-1
ii libprotobuf-c1 1.2.1-1
ii libreadline6 6.3-8+b4
ii libseccomp2 2.3.0-1
ii libsystemd0 229-4
ii libtalloc2 2.1.5-2
ii libtasn1-6 4.7-3
ii libwrap0 7.6.q-25
ii ssl-cert 1.0.37

Versions of packages ocserv recommends:
ii ca-certificates 20160104

ocserv suggests no packages.

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

-- no debconf information