Bug#826079: security update breaks pdns-server

[Martin]

Package: libbotan-1.10-0
Version: 1.10.8-2+deb8u1

The security update breaks pdns-server, libbotan version 1.10.8-2 was 
not giving me any problems. I am trying to run the latest pdns-server 
package (3.4.1-4+deb8u5) which is a rebuilt package for the latest 
libbotan package. Upgrading to 1.10.8-2+deb8u1 leaves me with an 
unresponsive pdns-server, no error messages. When I downgrade libbotan 
back to 1.10.8-2 everything is fine again.


It's a plain Debian installation (Jessie) that we keep up-to-date using 
apt-get.

Bug#826078: [python-serial] Package aborts configuration

[Valerio Passini]

Package: python-serial
Version: 3.1-1
Severity: grave

--- Please enter the report below this line. ---

As you can read here (exception for the Italian lines )
Estrazione di python-serial (3.1-1) su (3.0.1-1)...
Configurazione di python-serial (3.1-1)...
  File "/usr/lib/python2.7/dist-packages/serial/aio.py", line 366
def open_serial_connection(*,
^
SyntaxError: invalid syntax

dpkg: errore nell'elaborare il pacchetto python-serial (--configure):
 il sottoprocesso installato script di post-installation ha restituito lo 
stato di errore 101
Si sono verificati degli errori nell'elaborazione:
 python-serial

the new package cannot be properly configured.
At the moment I suggest to revert to the testing package. 
--- System information. ---
Architecture: amd64
Kernel:   Linux 4.5.6

Debian Release: stretch/sid
  990 unstablemi.mirror.garr.it 
  990 unstableftp.uk.debian.org 
  500 wheezy  activsoftware.co.uk 
  500 testing mi.mirror.garr.it 
  500 testing ftp.uk.debian.org 
  500 stable  mi.mirror.garr.it 
  500 stable  dl.google.com 
1 experimentalmi.mirror.garr.it 
1 experimentalftp.uk.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-===
python(>= 2.7) | 2.7.11-1
python(<< 2.8) | 2.7.11-1


Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-===
python-wxgtk3.0| 
 OR python-wxgtk   | 




-- 
Valerio

Bug#826075: dpkg: warning: while removing iceweasel, directory '/etc/iceweasel/searchplugins' not empty so not removed

[積丹尼 Dan Jacobson]

MH> This is the third time you reported this issue.

Sorry. OK I will purge it from all my machines.

Bug#826077: dash: fg %string does not work

[B. Ruva]

Package: dash
Version: 0.5.7-4+b1
Severity: normal

Dear Maintainer,

it is not possible with dash to resume suspended jobs with fg %string.

For example after suspending vi with Control-Z, the command

fg %vi

does not resume vi, but gives always the inappropriate error message:

sh: 8: fg: %vi: ambiguous

even if vi is the only active job.

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

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

Versions of packages dash depends on:
ii  debianutils  4.4+b1
ii  dpkg 1.17.25
ii  libc62.19-18+deb8u4

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#826075: dpkg: warning: while removing iceweasel, directory '/etc/iceweasel/searchplugins' not empty so not removed

[Mike Hommey]

reassign 826075 dpkg
forcemerge 816335 826075
thanks

Dan,

This is the third time you reported this issue.

Mike

On Thu, Jun 02, 2016 at 12:24:55PM +0800, 積丹尼 Dan Jacobson wrote:
> Package: iceweasel
> Version: 46.0~a2+20160217064514-1
> 
> Purging configuration files for iceweasel (46.0~a2+20160217064514-1) ...
> dpkg: warning: while removing iceweasel, directory
> '/etc/iceweasel/searchplugins' not empty so not removed
> 
> # find /etc/iceweasel -ls -delete
>330396  4 drwxr-xr-x   2 root root 4096  9月  9  2015 
> /etc/iceweasel/searchplugins/locale/en-US
>330395  4 drwxr-xr-x   3 root root 4096  8月 22  2014 
> /etc/iceweasel/searchplugins/locale
>330391  4 drwxr-xr-x   3 root root 4096  6月  2 12:18 
> /etc/iceweasel/searchplugins
>330408  4 drwxr-xr-x   2 root root 4096  3月  1 18:45 
> /etc/iceweasel/profile/chrome
>330404  4 drwxr-xr-x   3 root root 4096  3月  1 18:45 
> /etc/iceweasel/profile
>330388  4 drwxr-xr-x   4 root root 4096  6月  2 12:18 
> /etc/iceweasel
> 
> ___
> pkg-mozilla-maintainers mailing list
> pkg-mozilla-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozilla-maintainers

Bug#826063: RFS: libu2f-host/1.0.0-2 [NMU] [RC] -- U2F host communication library

[Adam Borowski]

control: tags -1 moreinfo

On Thu, Jun 02, 2016 at 01:31:02AM +0200, Nicolas Braud-Santoni wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my upload for the libu2f-host package.
> It fixes the following RC bug:
>   #820686: FTBFS - missing build-dep libglib2.0-dev
> 
> The package's maintainer team, the Debian Authentication Maintainers, has
>   not commented on the bug since it was opened, 2 months ago.
> 
> 
> The dsc and build artifacts can be found in
>   https://nicolas.braud-santoni.eu/tmp/deb/

The dsc there doesn't unpack -- filenames nor checksums don't match.

> They were produced, using pdebuild(1), from the source in
>   https://github.com/nbraud/libu2f-host-dpkg/tree/bug-820686
>   (signed commit 4e6802ca12362e415ee45fcab64f38a601b02420)
> 
> This changed has been submitted back to the packaging repo as a pull request:
>   https://github.com/Yubico/libu2f-host-dpkg/pull/1
> 
> It ignores the commits that got added since the last version that was 
> published
>   in the archive (esp. the merging of a new upstream version).

Only one of four commits atop of debian/1.0.0-1 looks relevant:
40d4511 has the following changes:
+ updated build-dependencies (ie, the meat of the NMU)
+ standards version bump
+ a changelog entry (with an error: you need # after "Closes: " before the
  number)

e12e613 adds an UNRELEASED changelog entry and some gbp junk.
3d0722a tries to invent a way of generating "orig" tarballs.
+ this is bad as those don't match upstream.  Besides details like losing
  timestamps or degrading xz to gz, you really should use what upstream
  provides, unless this is impossible because of git-only releases or a
  need to repack.
+ not using upstream tarballs ie especially bad as these are signed
4e6802c tries to ignore changes in a generated file instead of properly
  cleaning it (deletion would suffice)

On the other hand, something in clean-up after build does happen to break
the package.  If you try to package the source from a fresh repository, it
succeeds.  After a build, newly repacked source won't build anymore:

/bin/bash /home/kilobyte/tmp/pkg/libu2f-host-dpkg/build-aux/missing help2man \
--output=u2f-host.1 ./u2f-host \
--name="Yubico Universal 2nd Factor (U2F) Host Tool" \
--no-info
help2man: can't get `--help' info from ./u2f-host
Try `--no-discard-stderr' if option outputs to stderr
WARNING: 'help2man' is missing on your system.
 You should only need it if you modified a dependency of a man page.
 You may want to install the GNU Help2man package:
 
Makefile:952: recipe for target 'u2f-host.1' failed
make[4]: *** [u2f-host.1] Error 127


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#826076: RFS: lua-cwrap/0~20160222-gdbd0a62-1 -- CWrap package for Torch Framework [ITP]

[lumin]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

  Dear mentors,

  I am looking for a sponsor for my package "lua-cwrap"

 * Package name: lua-cwrap
   Version : 0~20160222-gdbd0a62-1
   Upstream Author : Torch Developers
 * URL : https://github.com/torch/cwrap
 * License : BSD-3-Clause-like
   Section : interpreters

  It builds those binary packages:

lua-cwrap  - CWrap package for Torch Framework

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/lua-cwrap


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/l/lua-cwrap/lua-cwrap_0~20160222-gdbd0a62-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

lua-cwrap (0~20160222-gdbd0a62-1) unstable; urgency=low

  * Initial release. Closes: #826073

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

On Tue, 2016-05-31 at 16:17 +, Gianfranco Costamagna wrote:
> Hi,
> 
> python-skimage should be RC free now (if no other RC bugs are opened of 
> course :) )
> 
> let me know when you have updates,
> 
> G.

Thank you for working on it !
:-)

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

On Thu, 2016-05-26 at 14:32 +0100, Ghislain Vaillant wrote:

> I don't agree. Regarding the testsuite, I believe most features should
> be tested at package build time, including the Python stuff. We want to
> fail early if something goes wrong. To me, the autopkgtest testsuite
> serves a different purpose, i.e. to test that an update in the install
> requirements does not break the currently uploaded package.

Isn't that done by piuparts? confused.
And yes I should also write a python tester script.

> So yes, the Python runtime dependencies should be part of Build-Depends
> and the Python testsuite should be called during the build.

I'll add them later.

>  From my experience using caffe at the lab, the Python interface is what
> people are mainly using. So IMO, it would be quite a let down if the
> caffe were uploaded without Python support.
> 
> IMO, it should be either Python 3 alone or Python 2 + 3. I made this
> mistake when packaging OpenGM and regret it now. I'll repeat it here,
> Python 2 has an expiration date and we should encourage people to use
> Python 3.

Let's make python3-caffe-* and let it be python3-only.

> I did not follow all the recent action on the packaging, but why are we
> still using templated install.in files instead of patching the build
> system for the great of the rest of the Linux community?

I indeed made all suggested changes including using `GNUInstallDirs`
to avoid template generation. Currently the *.in files are mostly
fake template (nothing to be replaced) but only
libcaffe-cpu-dev.install.in is the real one. I need to match
a library install directory in this file, which is the only
remaining template.

Oh yes I should rename those non-template files.
:-)

BTW, I tested the python3 build and I found that, the python3
version can be built without python3-protobuf, and the compilation
will not crash. Python3 module will be generated but when trying
to import caffe in python3 it will end up with something like:

error import google.protobuf

That is to say python3-protobuf is not a build-dep but a runtime-dep
for the python3 interface.

Bug#826075: dpkg: warning: while removing iceweasel, directory '/etc/iceweasel/searchplugins' not empty so not removed

[積丹尼 Dan Jacobson]

Package: iceweasel
Version: 46.0~a2+20160217064514-1

Purging configuration files for iceweasel (46.0~a2+20160217064514-1) ...
dpkg: warning: while removing iceweasel, directory
'/etc/iceweasel/searchplugins' not empty so not removed

# find /etc/iceweasel -ls -delete
   330396  4 drwxr-xr-x   2 root root 4096  9月  9  2015 
/etc/iceweasel/searchplugins/locale/en-US
   330395  4 drwxr-xr-x   3 root root 4096  8月 22  2014 
/etc/iceweasel/searchplugins/locale
   330391  4 drwxr-xr-x   3 root root 4096  6月  2 12:18 
/etc/iceweasel/searchplugins
   330408  4 drwxr-xr-x   2 root root 4096  3月  1 18:45 
/etc/iceweasel/profile/chrome
   330404  4 drwxr-xr-x   3 root root 4096  3月  1 18:45 
/etc/iceweasel/profile
   330388  4 drwxr-xr-x   4 root root 4096  6月  2 12:18 
/etc/iceweasel

Bug#752876: r-cran-spdep_0.6-4-1_amd64.changes REJECTED

[Andreas Tille]

Hi,

upstream has removed the file in question in SVN.  I excluded it in the
repackaged source tarball and applied the patches needed to the
remaining files and re-uploaded.  Fast-processing would be extremely
helpful.

Kind regards from Stockholm

 Andreas.

On Fri, May 13, 2016 at 01:00:23PM +, Thorsten Alteholz wrote:
> 
> Hi Andreas,
> 
> ok, one step further, but two questions remain:
> 
> - "... in its entirety ...", not being a native speaker, but for me that 
>   sounds like you are only allowed to distribute the whole example code 
>   and are not allowed to use just parts of it
> - anyway, the main point is that you are only allowed to redistribute 
>   the code but have no permission to modify it, which is against DFSG 3.
> 
>   Thorsten
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> -- 
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
> 

-- 
http://fam-tille.de

Bug#826074: vrms: Does not list package installed using .deb file.

[Ryan Murray]

Package: vrms
Version: 1.16
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

I needed to install non-free drivers for my printer. I realized
that installing packages using .deb files circumvents vrms (using dpkg
-i filename.deb). It would be nice if there was a way for the user to mark 
known non-free packages manually.

I like using vrms to "keep track" of the few non-free packages I have,
so I know to try and replace them with free alternatives eventually.

Thanks,
Ryan


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

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

-- no debconf information

Bug#719624: Upgrading xrdp

[Andreas Tille]

Without checking: After Building you get a *.changes file.  Open this
and check whether it has a Closes: line featuring all the bugs you want
to close.
Sorry for my brewity
Andreas.

On Thu, Jun 02, 2016 at 01:26:30AM +0200, Dominik George wrote:
> Hi,
> 
> one more question:
> 
> Is the „Closes:“ line in changelog syntactically correct to close all the 
> bugs?
> 
> -nik
> -- 
> PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
> 
> Dominik George · Mobil: +49-151-61623918
> 
> Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
> Fellowship of the FSFE · Piratenpartei Deutschland
> Opencaching Deutschland e.V. · Debian Contributor
> 
> LPIC-3 Linux Enterprise Professional (Security)
> 

-- 
http://fam-tille.de

Bug#820583: Another lengthy delay

[Don Barry]

Earlier, Jasper Wallace asked whether "this one of those situations
where some unfortunate volunteer has ended up becoming critical security
infrastructure?"

The current flash security update (from 616 to 621) is now two weeks
overdue from the upstream site, and the player has been blacklisted for
several days from Iceweasel.

Please, please, can we have discussions to bring additional people or
automation into this security infrastructure?  There were volunteers in
other bug reports.  Bart's work is most appreciated (I certainly
appreciate it) but that shouldn't preclude other people helping to
ensure timeliness.

Bug#826073: ITP: lua-cwrap/0~20160222-gdbd0a62 -- CWrap package for Torch Framework

[lumin]

Package:wnpp
Severity: wishlist
Owner: lumin 

* Package name: lua-cwrap
  Version : 0~20160222-gdbd0a62
  Upstream Author : Torch Developers
* URL : https://github.com/torch/cwrap
* License : BSD-3-Clause
  Programming Lang: lua
  Description : CWrap package for Torch Framework

 The cwrap package helps you to automate the generation of Lua/C wrappers
 around existing C functions, such that these functions would be callable
 from Lua. This package is used by the torch package, but does not depend
 on anything, and could be used by anyone using Lua.

This is the dependency table of Torch package:

/extra/luafilesystem  pass  <== exists in archive
/extra/penlight   pass  <== exists in archive
/extra/lua-cjson  pass  <== exists in archive

/extra/luaffifb   upstream?, dep lua >= 5.1
/pkg/sundown  upstream?, dep lua >= 5.1
/pkg/cwraporig, dep lua >= 5.1, can be used independent 
<== ITP: lua-cwrap
/pkg/pathsorig, dep lua >= 5.1
/pkg/torchorig, dep lua >= 5.1, dep paths >= 1.0, dep cwrap >= 1.0
/pkg/dok  orig, dep lua >= 5.1, dep sundown >= 1.0
/exe/treplorig, dep torch >= 7.0, dep penlight >= 1.1.0
/pkg/sys  orig, dep torch >= 7.0
/pkg/xlua orig, dep sys >= 1.0, dep torch >= 7.0
/extra/nn orig, dep torch >= 7.0, dep luaffi
/extra/graph  orig, dep torch >= 7.0
/extra/nngraphorig, dep torch >= 7.0, dep graph, dep nn
/pkg/imageorig, dep torch >= 7.0, dep sys >= 1.0, dep xlua >= 1.0, 
dep dok
/pkg/optimorig, dep torch >= 7.0, dep sys >= 1.0

Bug#826072: alevt: Program table overflow

[Frank Heckenbach]

Package: dvb-apps
Version: 1.1.1+rev1500-1+fh1
Severity: normal
File: /usr/bin/alevt
Tags: patch

progtbl has a size of 16 (actually, only 15 are used due to the
check "progcnt >= sizeof(progtbl)/sizeof(progtbl[0])"; maybe this
should be ">", unless the last entry is needed as a terminator).

Anyway, one channel I receive (DE-Nuremberg, DVB-T, 78600 Hz,
Eurosport etc.) has a size of 17, so it's too small either way and
alevt aborts with the message given in the subject.

I don't know if there are official size limits, or whether there are
side-effects to my change, but for now, just increasing the size
seems to work for me.

The same code exists in the alevt package, may need to be patched
there, too.

--- util/alevt/vbi.c
+++ util/alevt/vbi.c
@@ -628,7 +628,7 @@
u_int8_t txttype;
u_int8_t txtmagazine;
u_int8_t txtpage;
-   } progtbl[16], *progp;
+   } progtbl[32], *progp;
u_int8_t tbl[4096];
u_int8_t * ppname, * psname, pncode, sncode, pnlen, snlen;
int r;

Bug#826071: khotkeys built without XTest

[Christopher Martin]

Package: khotkeys
Version: 4:5.6.4-1

Hello,

Now that 5.6 supports gestures properly again, I turned them back on and
found that I could no longer middle click: when not performing a gesture
with the middle mouse button, khotkeys wasn't passing my middle clicks
through to the underlying applications. A quick search uncovered this:

https://www.reddit.com/r/kde/comments/4gffxp/mouse_gestures_break_middle_click

Essentially, khotkeys needs to be built with XTest support. It will then
pass clicks through to the underlying application once it has determined
that no gesture is being made.

Armed with this knowledge, I was able to solve the issue by rebuilding
khotkeys myself after installing libxtst-dev . The solution thus appears to
be simple - add that package to the khotkeys build-depends.

Thanks for your work packaging KDE.

Christopher Martin

Bug#825901: Internal error: couldn't generate list of packages to download

[積丹尼 Dan Jacobson]

> "MAFM" == Manuel A Fernandez Montecelo  
> writes:

MAFM> Do you have any more info to know why 8:6.8.9.9-7+b1 instead of +b2 is
MAFM> chosen?  What's the current status of imagemagick?  (e.g. half
MAFM> configured or something?).

All I know is the newer one makes a lot of dangling symlins so I had put
it on hold previouly.

I probably checked if I reported it before, and found 758792 and thought
that I did, but that turns out to be a previous bug. Now I am getting
these other bugs so I'm scared to try upgrading it again, and will wait
for a new imagemagick.

Now:
# set imagemagick
# apt-cache policy $@
imagemagick:
  Installed: 8:6.9.2.10+dfsg-1
  Candidate: 8:6.9.2.10+dfsg-2
  Version table:
 8:6.9.2.10+dfsg-2 990
990 http://free.nchc.org.tw/debian experimental/main i386 Packages
 *** 8:6.9.2.10+dfsg-1 100
100 /var/lib/dpkg/status
 8:6.8.9.9-7+b2 500
500 http://free.nchc.org.tw/debian unstable/main i386 Packages

I put it on hold again due to so many problems.

Bug#825981: failure message upon install

[積丹尼 Dan Jacobson]

> "MB" == Michael Biebl  writes:

MB> Can you attach your /etc/fstab please and the file /run/systemd/was-enabled.
MB> Is there a file /etc/systemd/system/tmp.mount (or was in the past)?

UUID=355d426a-cbfc-4faf-91d6-4f9405199517 /home auto defaults,commit=111 0 2
UUID=34610b6a-70a3-48d9-b135-96907dc2ba16 /var auto defaults,commit=111 0 2
UUID=1d11e0e3-26d7-42be-89d2-00fbe939dc1c / ext4 
defaults,commit=111,errors=remount-ro 0 1
UUID=ce5499e2-019e-44cc-8f95-d027832b3d7d none swap sw 0 0
tmpfs /tmp tmpfs defaults 0 0
UUID=26a1643a-011c-4d6b-8234-c327f9dc2495 /var/lib/apt/lists auto 
noauto,errors=remount-ro 0 0
UUID=82152152-fd1b-41f5-8860-a65f18de2275 /var/cache/apt/archives auto 
noauto,errors=remount-ro 0 0

P.S., because I have /home and /var on their own partitions,
I get red messages about not being able to unmount them upon shutdown.

If you recall not so few years ago we were taught to partition them that
way, and in fact there really is nothing wrong with still partitioning
them that way. Alas, systemd or whoever just assumes some different geometry.

P.S.S., because LINUX has no kernel variable DELAY_AT_HALT to allow me
to set a number of seconds to copy down the exact messages with a pad
and pencil, I can only tell you that I really see them.

$ ls -F /etc/systemd/system
bluetooth.target@hybrid-sleep.target.wants/paths.target.wants/
sysinit.target.wants/
getty.target.wants/  multi-user.target.wants/  sockets.target.wants/  
syslog.service@
hibernate.target.wants/  network-online.target.wants/  suspend.target.wants/  
timers.target.wants/

I don't know if there was one in the past.

Bug#826070: python-escript: FTBFS in indep-only mode: no prerm scripts to tweak

[Aaron M. Ucko]

Source: python-escript
Version: 4.2.0.1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Thanks for fixing python-escript's build dependencies quickly.
Architecture-specific builds now look good for the most part (aside
from portability issues to some non-release architectures), but the
arch-all-only build failed:

  sed -i -e 's/#PACKAGE#/python-escript/' debian/python-escript/DEBIAN/prerm
  sed: can't read debian/python-escript/DEBIAN/prerm: No such file or directory
  debian/rules:133: recipe for target 'override_dh_gencontrol' failed

Could you please take a look?  I think it might suffice to rename the
target to override_dh_gencontrol-indep.

Thanks!

Bug#826000: ifupdown: if-pre-up.d and if-up.d scripts are run twice at boot

[Vincent Lefevre]

On 2016-06-01 23:42:55 +0200, Guus Sliepen wrote:
> The text about IFACE being set to "--all" is two paragraphs down. But
> I'll clarify the manpage in the next release, and see about adding a log
> message when the scripts for --all are being run.

In the mean time, I've added a 0ifupdown script in each of the
4 if-*.d directories, which does:

logger -t ifupdown "IFACE=$IFACE ADDRFAM=$ADDRFAM METHOD=$METHOD PHASE=$PHASE"

This gives valuable information.

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

Bug#826069: libghemical5v5: breaks color rendering and atom generation in ghemical

[Carlo Segre]

Package: libghemical5v5
Version: 3.0.0-4.1+b2
Severity: grave
Justification: renders package unusable

When installed from sid, ghemical will only render in greyscale instead of 
color.  In addition, building a molecule atom-by-atom is not functional.

In order to get ghemical working again, I have to revert to the wheezy version
as there is no version available in jessie.

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/8 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 libghemical5v5 depends on:
ii  libblas3 [libblas.so.3]  3.6.0-2
ii  libc62.22-9
ii  libgcc1  1:6.1.1-4
ii  libghemical-data 3.0.0-4.1
ii  liblapack3 [liblapack.so.3]  3.6.0-2
ii  libmopac7-1gf1.15-6
ii  libopenmpi1.10   1.10.2-14
ii  libsc7v5 2.3.1-16.1+b1
ii  libstdc++6   6.1.1-4

libghemical5v5 recommends no packages.

libghemical5v5 suggests no packages.

-- no debconf information

Bug#826068: X11vnc layouts problem

[Dark Penguin]

Package: x11vnc
Version: 0.9.13-1.2+b2
Severity: normal


When the local layout is non-English, capital letters (and also "Shift-" 
keys) come out lower-case (or "without Shift").


Example:

- I connect to a Debian Jessie machine running x11vnc over MATE (I've 
also tried x11vnc on LMDE2 with Cinnamon) using Remmina on Debian Jessie 
or TightVNC on Windows. Both local and remote layouts are english by 
default. Everything is fine at this point.


- I press Alt+Shift to change layouts. This changes both local and 
remote layouts (to Russian, in my case, but I assume it would be the 
same with any non-English layout). Now, all upper-case that I type come 
out lower-case, and if I try to type '!' , I get '1' on the other side.


- If I change the remote layout by clicking it with my mouse, but leave 
my local layout non-English, the problem persists. However, if I change 
my local layout back to English, then the problem is gone, whichever 
layout there is on the remote side.



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

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

Versions of packages x11vnc depends on:
ii  libavahi-client3  0.6.31-5
ii  libavahi-common3  0.6.31-5
ii  libc6 2.19-18+deb8u4
ii  libjpeg62-turbo   1:1.3.1-12
ii  libssl1.0.0   1.0.1k-3+deb8u5
ii  libvncclient0 0.9.9+dfsg2-6.1+deb8u1
ii  libvncserver0 0.9.9+dfsg2-6.1+deb8u1
ii  libx11-6  2:1.6.2-3
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxinerama1  2:1.1.3-1+b1
ii  libxrandr22:1.4.2-1+b1
ii  libxtst6  2:1.2.2-1+b1
ii  openssl   1.0.1k-3+deb8u5
ii  tk8.6.0+8
ii  x11vnc-data   0.9.13-1.2
ii  zlib1g1:1.2.8.dfsg-2+b1

x11vnc recommends no packages.

x11vnc suggests no packages.

-- no debconf information


--
darkpenguin

Bug#807662: mrpt-common: fails to upgrade from 'jessie' - trying to overwrite /usr/share/mrpt/config_files/simul-beacons/example_simul-beacons.ini

[Andreas Beckmann]

Followup-For: Bug #807662
Control: found -1 1:1.4.0-1

Hi,

the Breaks+Replaces recently added are missing the epoch and are
therefore ineffective.


Andreas

Bug#826067: python-gi: module gi._gi_cairo not found

[Celelibi]

Package: python-gi
Version: 3.20.1-1
Severity: important

The module files installed in /usr/lib/python2.7/dist-packages/gi don't
include a non-debug version for _gi_cairo.

There is a version compiled with pydebug enabled that is installed. This
one is named _gi_cairo.i386-linux-gnu_d.so, with "_d" meaning pydebug is
enabled. Since python2 is compiled without pydebug, that makes it unable
to find this shared library.

In the attached test case, this module is tentatively loaded from the
function pygi_struct_foreign_load_module at gi/pygi-foreign.c:70 to
convert arguments to a callback python function. The failure to find a
suitable "foreign struct converter" is not shown to the user.

This bug seriously undermines the ability to use Gtk3 from python2.


Best regards,
Celelibi

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

Kernel: Linux 3.10.11 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python-gi depends on:
ii  gir1.2-glib-2.01.48.0-2
ii  libc6  2.22-7
ii  libffi63.2.1-4
ii  libgirepository-1.0-1  1.48.0-2
ii  libglib2.0-0   2.48.1-1
ii  python 2.7.11-1
pn  python:any 

python-gi recommends no packages.

Versions of packages python-gi suggests:
pn  python-gi-cairo  

-- no debconf information
#!/usr/bin/python

import sys

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
import cairo
import math

def OnDraw(w, cr):
print("OnDraw")
cr.set_source_rgb(1, 1, 0)
cr.arc(320,240,100, 0, 2*math.pi)
cr.fill_preserve()

cr.set_source_rgb(0, 0, 0)
cr.stroke()

cr.arc(280,210,20, 0, 2*math.pi)
cr.arc(360,210,20, 0, 2*math.pi)
cr.fill()

cr.set_line_width(10)
cr.set_line_cap(cairo.LINE_CAP_ROUND)
cr.arc(320, 240, 60, math.pi/4, math.pi*3/4)
cr.stroke()

w = Gtk.Window()
w.set_default_size(640, 480)
a = Gtk.DrawingArea()
w.add(a)

w.connect('destroy', Gtk.main_quit)
a.connect('draw', OnDraw)

w.show_all()

Gtk.main()

Bug#826066: RFS: gmp-ecm/7.0.1+ds-1 [RC] -- factor integers using the Elliptic Curve Method

[Jerome Benoit]

Package: sponsorship-requests
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Sponsors,

I am looking for sponsorship for the package gmp-ecm, a mathematical
suite to factor integers. This very package brings a new micro upstream
release that fixes FTBFS issues on some exotic machines.

Thanks in advance,
Jerome


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

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#826065: tk-mpeg,saods9-tclpackages: error when trying to install together

[Andreas Beckmann]

Followup-For: Bug #826065
Control: affects -1 tk-html1
Control: found -1 tk-html1/1.0.2-1

There are similar problems with tk-html1 in sid and saods9-tclpackages
in experimental:

  Selecting previously unselected package saods9-tclpackages:amd64.
  Preparing to unpack .../saods9-tclpackages_7.5~b1+repack-1_amd64.deb ...
  Unpacking saods9-tclpackages:amd64 (7.5~b1+repack-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/saods9-tclpackages_7.5~b1+repack-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/tcltk/x86_64-linux-gnu/tkhtml11.0/libtkhtml11.0.so', which is also in 
package tk-html1 1.0.2-1
  Errors were encountered while processing:
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
   /var/cache/apt/archives/saods9-tclpackages_7.5~b1+repack-1_amd64.deb


Andreas

Bug#826065: tk-mpeg,saods9-tclpackages: error when trying to install together

[Andreas Beckmann]

Package: tk-mpeg,saods9-tclpackages
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 7.4.1+repack-1
Control: found -1 1.0-1

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Selecting previously unselected package tk-mpeg.
  Preparing to unpack .../tk-mpeg_1.0-1_amd64.deb ...
  Unpacking tk-mpeg (1.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/tk-mpeg_1.0-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/tcltk/x86_64-linux-gnu/tkmpeg1.0/libtkmpeg1.0.so', which is also in 
package saods9-tclpackages:amd64 7.4.1+repack-1
  Errors were encountered while processing:
   /var/cache/apt/archives/tk-mpeg_1.0-1_amd64.deb

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  usr/lib/tcltk/x86_64-linux-gnu/tkmpeg1.0/libtkmpeg1.0.so
  usr/lib/tcltk/x86_64-linux-gnu/tkmpeg1.0/pkgIndex.tcl

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.


Probably both packages need to get active here:
* saods9-tclpackages needs to stop shipping these files
  and add a dependency on tk-mpeg instead
* tk-mpeg needs to add Breaks+Replaces against the saods9-tclpackages
  versions that shipped these files


Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html

Bug#824384: clearsilver: FTBFS: /usr/share/cdbs/1/class/python-module.mk:54: *** unterminated call to function 'strip': missing ')'. Stop.

[Vincent Cheng]

Hi Chris,

I can't reproduce this FTBFS at all using an up-to-date pbuilder sid
chroot. According to your build log:

>  Get:10 http://httpredir.debian.org/debian sid/main amd64 cdbs all 0.4.132 
> [79.1 kB]

That might be the culprit. It looks like cdbs has gone through a lot
of changes in sid in the last month, and using a newer version of cdbs
should make this FTBFS go away. Can you please try a rebuild with
cdbs/0.4.137 installed?

Regards,
Vincent

Bug#826064: yaws: how invoke-rc.d script works?

[Alexandros Prekates]

Source: yaws
Severity: wishlist

Dear Maintainer,

how invoke-rc.d script works?

For example i change one directive to a virt_serv conf file (like a port)
and then execute:
# invoke-rc.d yaws reload
but i dont see the change.

But if i restart with :
# service yaws stop
# service yaws start

then the change is seen.



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

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

Bug#825877: firejail: conffiles not removed

[Reiner Herrmann]

On Thu, Jun 02, 2016 at 12:35:33AM +0200, Reiner Herrmann wrote:
> I understand that it is a problem that files are not cleaned up.
> But when they are not automatically removed, this means that the user
> has manually touched/modified them.  The changes made either to the
> includes or to profiles could still be relevant and in use by some
> files, e.g. the user could be maintaining an extensive blacklist in
> disable-secret.inc.
> So even if they are no longer part of upstream's set of profiles, they
> might not be obsolete in all cases.

I seem to have confused something. I thought obsolete conffiles would
already be removed automatically if they have not been touched, but
this is not the case.
After reading dpkg-maintscript-helper(1), rm_conffile sounds much more
graceful than I expected.  I will provide better cleanup in the next
upload.

Thanks for the suggestion!


signature.asc
Description: Digital signature

Bug#826048: [Debian-med-packaging] Bug#826048: Faulty CMake file impairs compiling against GDCM

[Peter Mattern]

Thanks for your reply. But IMO it is missing the point.

Maybe we should first reconsider the workflow that takes place.
An application, here Ginkgo CADx, is sort of querying CMake like "Could you 
please tell
me which library is providing feature foo?" and CMake replies "Sure. It's 
library

/usr/lib/x86_64-linux-gnu/libFoo.so.".

Due to the sophisticated packaging in Debian it may very well happen that 
libFoo.so isn't
accessible right when cmake gets invoked simply as the package providing 
the library isn't

installed.
This is what I had in mind writing the "side note" in the initial posting 
and what you

were referring to in your reply.

But the problem addressed in this report is CMake returning faulty paths or 
files that aren't

available in the distribution at all besides they do belong to GDCM.
Could you by any chance have another look at the paragraphs after the two 
messages above?
libvtkgdcmsharpglue.so *was installed* when cmake got invoked but wasn't 
found as CMake didn't
know the correct path. libvtkgdcmPython.so *isn't available at all* in 
stretch besides it is
basically part of GDCM. Apparently it was succeeded by 
libvtkgdcmPython.x86_64-linux-gnu.so but

again CMake just isn't aware of this.
And both shouldn't happen, should it?

Bug#826063: RFS: libu2f-host/1.0.0-2 [NMU] [RC] -- U2F host communication library

[Nicolas Braud-Santoni]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my upload for the libu2f-host package.
It fixes the following RC bug:
  #820686: FTBFS - missing build-dep libglib2.0-dev

The package's maintainer team, the Debian Authentication Maintainers, has
  not commented on the bug since it was opened, 2 months ago.


The dsc and build artifacts can be found in
  https://nicolas.braud-santoni.eu/tmp/deb/

They were produced, using pdebuild(1), from the source in
  https://github.com/nbraud/libu2f-host-dpkg/tree/bug-820686
  (signed commit 4e6802ca12362e415ee45fcab64f38a601b02420)

This changed has been submitted back to the packaging repo as a pull request:
  https://github.com/Yubico/libu2f-host-dpkg/pull/1

It ignores the commits that got added since the last version that was published
  in the archive (esp. the merging of a new upstream version).


Best,

  nicoo

Bug#719624: Upgrading xrdp

[Dominik George]

Hi,

one more question:

Is the „Closes:“ line in changelog syntactically correct to close all the bugs?

-nik
-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-151-61623918

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#826062: ifupdown: FTBFS on kfreebsd: testsuite failures (whitespace change in output?)

[Andreas Beckmann]

Source: ifupdown
Version: 0.8.11
Severity: important

Hi,

since version 0.8.11 ifupdown does FTBFS on kfreebsd-any with testsuite
failures. These look mostly like whitespace changes in the output:

https://buildd.debian.org/status/fetch.php?pkg=ifupdown=kfreebsd-amd64=0.8.12=1463666413
https://buildd.debian.org/status/fetch.php?pkg=ifupdown=kfreebsd-i386=0.8.12=1463666483

   dh_auto_test -a -O--parallel
make -j2 check
make[1]: Entering directory '/«PKGBUILDDIR»'
running ./tests/testbuild-kfreebsd
Testcase 1: -a
--- tests/up.1  2016-05-19 14:01:20.0 +
+++ tests/up-res.1  2016-05-19 14:01:20.0 +
@@ -1,6 +1,7 @@
 stdout
 stderr
 /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
+
 Configuring interface eth0=eth0 (inet)
 /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
 
(failed)
==
Testcase 2: -a
--- tests/up.2  2016-05-19 14:01:20.0 +
+++ tests/up-res.2  2016-05-19 14:01:20.0 +
@@ -1,36 +1,42 @@
 stdout
 stderr
 /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
+
 Configuring interface eth0=eth0 (inet)
 /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
 
 /sbin/ifconfig eth0 1.2.3.4 netmask 255.255.255.0  up
 
 /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
+
 Configuring interface eth1=eth1 (inet)
 /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
 
 /sbin/ifconfig eth1 1.3.4.5 netmask 255.255.255.0  up
 
[...]



Cheers,

Andreas

Bug#719624: Upgrading xrdp

[Andreas Tille]

Hi Dominik,

On Thu, Jun 02, 2016 at 12:44:18AM +0200, Dominik George wrote:
> newest version is in collab-maint, issues seem to be resolved.
> 
> Please test, and, if satisfied, feel free to upload ;).

Very good.  Unfortunately I can not test before next Monday.  Mike
if you can run a test and upload this would be great.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#826061: nginx: FTBFS on kfreebsd: incomplete type 'struct in6_pktinfo'

[Andreas Beckmann]

Source: nginx
Version: 1.10.1-1
Severity: important

Hi,

ngingx FTBFS on kfreebsd-any since version 1.9.14-1, probably due to a
missing #include:

https://buildd.debian.org/status/fetch.php?pkg=nginx=kfreebsd-amd64=1.10.1-1=1464724938
https://buildd.debian.org/status/fetch.php?pkg=nginx=kfreebsd-i386=1.10.1-1=1464724962

cc -c -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -I src/core -I src/event -I src/event/modules -I 
src/os/unix -I /usr/include/libxml2 -I objs \
-o objs/src/event/ngx_event_accept.o \
src/event/ngx_event_accept.c
src/event/ngx_event_accept.c: In function 'ngx_event_accept':
src/event/ngx_event_accept.c:65:17: warning: implicit declaration of function 
'accept4' [-Wimplicit-function-declaration]
 s = accept4(lc->fd, (struct sockaddr *) sa, ,
 ^
In file included from /usr/include/i386-kfreebsd-gnu/sys/socket.h:38:0,
 from src/os/unix/ngx_posix_config.h:83,
 from src/core/ngx_config.h:42,
 from src/event/ngx_event_accept.c:8:
src/event/ngx_event_accept.c: In function 'ngx_event_recvmsg':
src/event/ngx_event_accept.c:348:55: error: invalid application of 'sizeof' to 
incomplete type 'struct in6_pktinfo'
 u_char msg_control6[CMSG_SPACE(sizeof(struct in6_pktinfo))];
   ^
src/event/ngx_event_accept.c:546:43: error: dereferencing pointer to incomplete 
type 'struct in6_pktinfo'
 sin6->sin6_addr = pkt6->ipi6_addr;
   ^
objs/Makefile:656: recipe for target 'objs/src/event/ngx_event_accept.o' failed
make[3]: *** [objs/src/event/ngx_event_accept.o] Error 1


Cheers,

Andreas

Bug#826043: apt: gpg validation fails on hurd

[Samuel Thibault]

Samuel Thibault, on Thu 02 Jun 2016 00:15:11 +0200, wrote:
> More precisely, running it from a directory which has perms 700 gets the
> issue.

Ok, I see the issue.  What happens is that nowadays apt uses an _apt
user to do some operations, and notably running

find -L /etc/apt/trusted.gpg.d/ -type f -name *.gpg

from the cmdline/apt-key.in script.

To do its work, find first records the $PWD, then goes to
/etc/apt/trusted.gpg.d/ to find the files, and then goes back to $PWD.

On Linux, getting $PWD from the 700 directory happens to work by luck
(POSIX says that getcwd can return [EACCES]: Search permission was denied
for the current directory, or read or search permission was denied for a
directory above the current directory in the file hierarchy). And going
back to $PWD fails, and thus find returns 1, but at least it emitted its
output.

On Hurd, getting $PWD from the 700 directory fails, and find thus aborts
immediately, without emitting any output, and thus no keyring is found.

So, to summarize, the issue is that since apt-get update runs find as a
non-root user, running it from a 700 directory breaks find.

I guess it may make sense for apt to chdir to e.g. / before running the
find command, so that we are sure that find doesn't get any issue?

Actually it's pure luck that the script doesn't completely fail on Linux
when find fails due to not being able to restore the cwd: since the find
command is only used as parameter of a for loop, the returned value
is ignored by sh. Had the find command output been first stored in a
variable, the script would have aborted...

Samuel

Bug#826060: RFS: libu2f-server/1.0.1-1 [NMU] [RC] -- U2F server communication library

[Nicolas Braud-Santoni]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my upload for the libu2f-server package.
It fixes the following RC bug:
  #820690: FTBFS - missing build-dep libglib2.0-dev

The package's maintainer team, the Debian Authentication Maintainers, has
  not commented on the bug since it was opened, 2 months ago.


The dsc and build artifacts can be found in
  https://nicolas.braud-santoni.eu/tmp/deb/

They were produced, using pdebuild(1), from the source in
  https://github.com/nbraud/libu2f-server-dpkg/tree/bts-820690
  (signed commit 8b88a9836e9904049f4f9c384f1db571b6b08bac)

This changed has been submitted back to the packaging repo as a pull request:
  https://github.com/Yubico/libu2f-server-dpkg/pull/2


Best,

  nicoo

Bug#822612: Perfect_Dentist - melanie

[Melanie Bussell]

I have a dentist already. Please don't email anymore
On Jun 1, 2016 6:43 PM, "1--8OOODentist"  wrote:

> Find The__Perfect___Dentist__In__Your Zone__For__Free__Now
> 
>
>

Bug#822612: Perfect_Dentist - Nancy

[Nancy Salinas]

I really want information to get implants I have Sjgrems Syndrome and my
teeth are decaying give me information on that please Nancy Salinas

On Wednesday, June 1, 2016, 1--8OOODentist  wrote:

> Find The__Perfect___Dentist__In__Your Zone__For__Free__Now
> 
>
>

Bug#822612: Perfect_Dentist - Joyce

[Joyce Calfee]

ZIP CODE 24739
On Jun 1, 2016 6:43 PM, "1--8OOODentist"  wrote:

> Find The__Perfect___Dentist__In__Your Zone__For__Free__Now
> 
>
>

Bug#826059: java may crash when loading a class named java

[Evgeny Kapun]

Package: openjdk-8-jre-headless
Version: 8u91-b14-2
Tags: patch

JVM may crash when trying to load a class named "java" in default package.

How to reproduce:
* Create a file named "java.java" with content "class java{}".
* Compile it: `javac java.java'.
* Try to run it: `java -cp "$PWD" java'. For some reason, running without `-cp' 
flag doesn't seem to trigger it.
* It may not crash on the first try. It may be necessary to run it multiple 
times before it crashes.

I attached a patch that should fix this problem.
--- a/hotspot/src/share/vm/classfile/systemDictionary.cpp
+++ b/hotspot/src/share/vm/classfile/systemDictionary.cpp
@@ -1087,6 +1087,7 @@
   if (!HAS_PENDING_EXCEPTION &&
   !class_loader.is_null() &&
   parsed_name != NULL &&
+  parsed_name->utf8_length() >= strlen(pkg) &&
   !strncmp((const char*)parsed_name->bytes(), pkg, strlen(pkg))) {
 // It is illegal to define classes in the "java." package from
 // JVM_DefineClass or jni_DefineClass unless you're the bootclassloader

Bug#822612: Perfect_Dentist - don

[Don Mount]

Fuck off!
On Jun 1, 2016 3:43 PM, "1--8OOODentist"  wrote:

> Find The__Perfect___Dentist__In__Your Zone__For__Free__Now
> 
>
>

Bug#719624: Upgrading xrdp

[Dominik George]

Hi,

newest version is in collab-maint, issues seem to be resolved.

Please test, and, if satisfied, feel free to upload ;).

Cheers,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-151-61623918

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

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

Bug#826057: subversion: please Build-Depend on rename

[Dominic Hargreaves]

Source: subversion
Version: 1.9.4-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.24-transition rename-deprecation

Dear maintainer,

This package was found to contain uses of the 'rename' and/or 'prename'
(which is an alias) command. This was previously implemented by a script
added to the perl package by Debian, but there is now a maintained
alternative in the 'rename' package.

Please add a Build-Depends on 'rename', to avoid breakage in your
package when we remove the rename script from the perl package
(expected after the release of stretch). Additionally, if you are
currently using 'prename', please use 'rename' (which is handled by the
alternatives mechanism) or file-rename, which is the new implementation.

You can see more background about this change at
.

Thanks,
Dominic

Details of the use of (p)rename in your package follow:

debian/rules
377:prename 's/\.(sh|pl|rb|py)$$//' debian/*/usr/bin/*

Bug#826000: ifupdown: if-pre-up.d and if-up.d scripts are run twice at boot

[Vincent Lefevre]

On 2016-06-01 23:42:55 +0200, Guus Sliepen wrote:
> You're skipping over the check for METHOD, which is set to "none" when
> IFACE is "--all":
> 
> case "$METHOD" in
>   static|dhcp|NetworkManager) ;;
>   *) exit 0 ;;
> esac

Oops, yes, I must be a bit tired (it also checks $ADDRFAM, BTW).

However, for the postfix script, the only test is "$IFACE" = "lo".
What the script does might be harmless, but it's difficult to say
whether that's always the case in all configs. Anyway, this is
certainly not what is expected.

The ethtool also just tests "$IFACE" != "lo". However, I think that
if there are no IF_* variables, this is OK. Now, it would be safer
and clearer to exit earlier in the --all case.

openssh-server is OK but just by chance: According to the comment,
it seems that the goal of the $ADDRFAM test was to reject ipx. So,
there's a risk that the code gets incorrectly simplified in the
future.

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

Bug#826058: webgui: please Build-Depend on rename

[Dominic Hargreaves]

Source: webgui
Version: 7.10.29-3
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.24-transition rename-deprecation

Dear maintainer,

This package was found to contain uses of the 'rename' and/or 'prename'
(which is an alias) command. This was previously implemented by a script
added to the perl package by Debian, but there is now a maintained
alternative in the 'rename' package.

Please add a Build-Depends on 'rename', to avoid breakage in your
package when we remove the rename script from the perl package
(expected after the release of stretch). Additionally, if you are
currently using 'prename', please use 'rename' (which is handled by the
alternatives mechanism) or file-rename, which is the new implementation.

You can see more background about this change at
.

Thanks,
Dominic

Details of the use of (p)rename in your package follow:

debian/rules
39: prename 's{\.pl\z}{}' $(TMP)/usr/bin/*.pl
43: prename 's{/([^/]+)\z}{/wg-$$1}' $(TMP)/usr/bin/*

Bug#826055: mysql-sandbox please Build-Depend on rename

[Dominic Hargreaves]

Source: mysql-sandbox
Version: 3.1.04-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.24-transition rename-deprecation

Dear maintainer,

This package was found to contain uses of the 'rename' and/or 'prename'
(which is an alias) command. This was previously implemented by a script
added to the perl package by Debian, but there is now a maintained
alternative in the 'rename' package.

Please add a Build-Depends on 'rename', to avoid breakage in your
package when we remove the rename script from the perl package
(expected after the release of stretch). Additionally, if you are
currently using 'prename', please use 'rename' (which is handled by the
alternatives mechanism) or file-rename, which is the new implementation.

You can see more background about this change at
.

Thanks,
Dominic

Details of the use of (p)rename in your package follow:

debian/rules
12: rename 's/\.sh//' $(TMP)/usr/bin/*.sh

Bug#826056: smokeping: please Build-Depend on rename

[Dominic Hargreaves]

Source: smokeping
Version: 2.6.11-3
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.24-transition rename-deprecation

Dear maintainer,

This package was found to contain uses of the 'rename' and/or 'prename'
(which is an alias) command. This was previously implemented by a script
added to the perl package by Debian, but there is now a maintained
alternative in the 'rename' package.

Please add a Build-Depends on 'rename', to avoid breakage in your
package when we remove the rename script from the perl package
(expected after the release of stretch). Additionally, if you are
currently using 'prename', please use 'rename' (which is handled by the
alternatives mechanism) or file-rename, which is the new implementation.

You can see more background about this change at
.

Thanks,
Dominic

Details of the use of (p)rename in your package follow:

debian/rules
38: rename 's/\.dist$$//' $(TMP)/etc/smokeping/*.dist

Bug#825877: firejail: conffiles not removed

[Reiner Herrmann]

Hi pabs!

On Tue, May 31, 2016 at 12:47:24PM +0800, Paul Wise wrote:
> The experimental version does not not deal with obsolete conffiles
> properly. Please use the dpkg-maintscript-helper support provided by
> dh_installdeb to remove these obsolete conffiles on upgrade.
> 
[...]
> 
> $ pkg=firejail ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | 
> grep obsolete
> firejail: obsolete-conffile /etc/firejail/disable-mgmt.inc
> firejail: obsolete-conffile /etc/firejail/disable-secret.inc
>  /etc/firejail/disable-mgmt.inc 50bda0b6c6837b0ee7409255b445037a obsolete
>  /etc/firejail/disable-secret.inc 9372a028cb5e15d15d1a95aa55d4015a obsolete

Thanks for reporting this issue.

I understand that it is a problem that files are not cleaned up.
But when they are not automatically removed, this means that the user
has manually touched/modified them.  The changes made either to the
includes or to profiles could still be relevant and in use by some
files, e.g. the user could be maintaining an extensive blacklist in
disable-secret.inc.
So even if they are no longer part of upstream's set of profiles, they
might not be obsolete in all cases.

Should they be removed anyway, even if there is the possibility that
it breaks a manual configuration by the user?

Regards,
  Reiner


signature.asc
Description: Digital signature

Bug#826053: libtext-ngrams-perl: please Build-Depend on rename

[Dominic Hargreaves]

Source: libtext-ngrams-perl
Version: 2.005-2
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.24-transition rename-deprecation

Dear maintainer,

This package was found to contain uses of the 'rename' and/or 'prename'
(which is an alias) command. This was previously implemented by a script
added to the perl package by Debian, but there is now a maintained
alternative in the 'rename' package.

Please add a Build-Depends on 'rename', to avoid breakage in your
package when we remove the rename script from the perl package
(expected after the release of stretch). Additionally, if you are
currently using 'prename', please use 'rename' (which is handled by the
alternatives mechanism) or file-rename, which is the new implementation.

You can see more background about this change at
.

Thanks,
Dominic

Details of the use of (p)rename in your package follow:

debian/rules
11: rename -v 's/\.pl//' $(TMP)/usr/bin/*.pl
12: rename -v 's/\.pl//' $(TMP)/usr/share/man/man1/*

Bug#826054: libvm-ec2-perl: please Build-Depend on rename

[Dominic Hargreaves]

Source: libvm-ec2-perl
Version: 1.28-1
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.24-transition rename-deprecation

Dear maintainer,

This package was found to contain uses of the 'rename' and/or 'prename'
(which is an alias) command. This was previously implemented by a script
added to the perl package by Debian, but there is now a maintained
alternative in the 'rename' package.

Please add a Build-Depends on 'rename', to avoid breakage in your
package when we remove the rename script from the perl package
(expected after the release of stretch). Additionally, if you are
currently using 'prename', please use 'rename' (which is handled by the
alternatives mechanism) or file-rename, which is the new implementation.

You can see more background about this change at
.

Thanks,
Dominic

Details of the use of (p)rename in your package follow:

debian/rules
11: rename 's/\.pl//' $(TMP)/usr/bin/*.pl
12: rename 's/\.pl//' $(TMP)/usr/share/man/man1/*

Bug#820704: Bug#820705: RFS: subuser/0.5.6-3 [ITP]

[Stanislas Leduc]

Hi, 

I follow your recommendations and push again new version : 

- Ajust debian/changelog 

- Modify debian/control and debian/rules 

Also for moment not include doc, WIP, discuss with developer because doc
include mp4 video. 

Thx for your review :) 

--- 

Stanislas Leduc

Bug#721617: [liblo] Bug#721617: pyliblo: FTBFS on sparc: testSendOthers (unit.ServerTestCase) ... Bus error (core dumped)

[John Paul Adrian Glaubitz]

On 06/02/2016 12:01 AM, Stephen Sinclair wrote:
> That's a good attitude, currently I don't know anyone using sparc64
> with liblo nor do I have access to such a machine, so reproducing and
> testing, and therefore fixing, this bug is not possible for me.  So, I
> look forward to your contribution.

We have a large machine available on which I can create an account for
you if you want to look at the problem yourself. It runs Debian unstable
with a current kernel and toolchain.

If you're interested, send me a private email with your public SSH key
and sign the mail with your GPG key if possible.

>> Which is absolutely not specific to SPARC. The moment you are recasting
>> a pointer that way, you are leaving the territory of the C99 specification
>> which explicitly states that declarations which refer to the same object must
>> have compatible types, otherwise the behavior is undefined (C99, 6.2.7/2) 
>> [1].
> 
> It is a good point.  If you have some examples where this fails it
> would be a good contribution to our unit testing.  (testlo.c)
> 
> At the moment no one has actually complained about this bug, and
> therefore I can only assume it has not actually been encountered and
> remains an entirely theoretical bug, but I do welcome ideas for how to
> fix it nonetheless, because compatibility with future architectures is
> certainly a desirable goal.

The problem is that this violates strict aliasing and can lead to
unpredictable results. I don't know enough about liblo though
to understand the ramifications without looking at the code.

>> The code in question is therefore buggy and has to be fixed anyway as there
>> is otherwise no guarantee it will work on future architectures or compilers.
>>
>> I'll have a look at this issue, it's a common programming mistake.
> 
> Unfortunately one that seems to be baked into the liblo API, but
> perhaps there is a way to fix it without sacrificing efficiency, at
> least on unaffected architectures.

Well, you can do these casts, but when you copy data, you must actually
use memcpy instead of a direct assignment. Then the compiler will
automatically take care of the proper alignment.

To fix those issues, it's normally enough to build with debug symbols
enabled, run gdb over it and the corresponding assignment will show
in the backtrace. Replacing the assignment with memcpy then fixes
the issue. I just recently did that for systemd [1].

Adrian

> [1] https://github.com/systemd/systemd/pull/3360

-- 
 .''`.  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

Bug#826052: New release available

[Peter Mattern]

Source: vtk6
Severity: normal

Upstream released 7.0.0 in February.

On the one hand this is simply the current stable release and as such sure good 
to have in
Debian anyway.
That aside this particular release is introducing changes regarding the header 
files. So
including it in Debian would help adjust other software to these changes as 
well.

The topic was already addressed in #805010 which was mainly dealing with 
release 6.3.0 and
got hence closed as fixed.

Bug#826043: apt: gpg validation fails on hurd

[Samuel Thibault]

Samuel Thibault, on Thu 02 Jun 2016 00:08:58 +0200, wrote:
> Samuel Thibault, on Wed 01 Jun 2016 23:40:16 +0200, wrote:
> > apt-get install --reinstall debian-archive-keyring
> > 
> > didn't fix it.
> > 
> > dpkg --force-depends -P debian-archive-keyring
> > dpkg -i /var/cache/apt/archives/debian-archive-keyring*
> > 
> > did fix it.
> 
> Ah, no, it's just that running apt-get update from /root has the issue,
> and running it from elsewhere doesn't have the issue (!?)

More precisely, running it from a directory which has perms 700 gets the
issue.

Samuel

Bug#826043: apt: gpg validation fails on hurd

[Samuel Thibault]

Samuel Thibault, on Wed 01 Jun 2016 23:40:16 +0200, wrote:
> apt-get install --reinstall debian-archive-keyring
> 
> didn't fix it.
> 
> dpkg --force-depends -P debian-archive-keyring
> dpkg -i /var/cache/apt/archives/debian-archive-keyring*
> 
> did fix it.

Ah, no, it's just that running apt-get update from /root has the issue,
and running it from elsewhere doesn't have the issue (!?)

Samuel

Bug#820128: vlc: Hardware decode issues/Video stops after a few seconds

[Petter Reinholdtsen]

Control: tags -1 - moreinfo
Control: reassign -1 libvdpau-va-gl1

[Sebastian Ramacher]
>> So here's the post for more details:
>> 
>> https://forum.videolan.org/viewtopic.php?f=13=131509
> 
> The log there suggests you have libvdpau-va-gl1 installed. Does the issue go
> away if you remove it?

According to a message in the forum thread dated 2016-04-17, the error
went away when removing the libvdpau-va-gl1 package.  I guess this bug should be
reassigned to libvdpau-va-gl1 as the problem seem to be in that code?  Doing so.

-- 
Happy hacking
Petter Reinholdtsen

Bug#826044: needrestart: Hangs in apt hook with a zombie

[Axel Beckert]

Hi Thomas,

Thomas Liske wrote:
> could you please provide your needrestart config (if changed from
> defaults)?

"debsums -ce needrestart" says no, so no file shipped by the package
is modifed.

I also checked /etc/needrestart/*.d for additional files, but except
backup files, there seems nothing changed:

This is from one of my previous bug reports and I'm now using the
packaged file again:

-rwxr-xr-x 1 root root 1359 May 17 18:56 600-mail*
-rwxr-xr-x 1 root root 1361 May 13 15:12 600-mail.dpkg-old*
-rwxr-xr-x 1 root root 1363 Mar 10 19:40 600-mail~*

> Is the problem reproducable?

Haven't tried until the end of this mail. See below. (Spoiler: No,
it's not.)

> Could you attach strace to needrestart while it hangs?

Impossible: The process more or less no more exists:

# strace -p 24169
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
#

And actually needrestart did all its output:

Scanning processes...
Scanning candidates...
Scanning linux images...
Running kernel seems to be up-to-date.
Restarting services...

Package configuration
┌┤ Daemons using outdated libraries ├─┐
│ │
│ │
│ Which services should be restarted? │
│ │
│[*] acpid│
│[*] atd  │
│[*] cgmanager│
│[*] cgproxy  │
│[*] clamav-freshclam │
│[*] cronie   │
│[ ] dbus │
│[*] dnssec-triggerd  │
│[*] fail2ban │
│[*] gpm  │
│[*] kerneloops   │
│[*] lvm2-lvmetad │
│[*] lvm2-lvmpolld│
│[*] lxcfs│
│[*] mdadm│
│[*] mdadm-waitidle   │
│[*] mpd  │
│[*] ntp  │
│[*] openbsd-inetd│
│[*] postfix  │
│[*] quasselcore  │
│[*] robustirc-bridge │
│[*] rollerd  │
│[*] rsyslog  │
│[*] spacenavd│
│[*] ssh  │
│[*] tor  │
│[*] unbound  │
│[*] uptimed  │
│[ ] wdm  │
│ │
│ │
│ │
│ │
└─┘

 service acpid restart
 service atd restart
 service cgmanager restart
 service cgproxy restart
 service clamav-freshclam restart
 service cronie restart
 service dnssec-triggerd restart
 service fail2ban restart
 service gpm restart
 service kerneloops restart
 service lvm2-lvmetad restart
 service lvm2-lvmpolld restart
 service lxcfs restart
 service mdadm restart
 service mdadm-waitidle restart
 service mpd restart
 service ntp restart
 service openbsd-inetd restart
 service postfix restart
 service quasselcore restart
 service robustirc-bridge restart
start-stop-daemon: unable to stat //robustirc-bridge (No such file or directory)
 service rollerd restart
 service rsyslog restart
 service spacenavd restart
 service ssh restart
 service tor restart
 service unbound restart
 service uptimed restart
Services being skipped:
 service dbus restart
 service wdm restart
No containers need to be restarted.
User sessions running outdated binaries:
 abe @ /dev/pts/0: emacs[19225], iceweasel[5134], liferea[5241], zsh[4193]
 abe @ /dev/pts/1: zsh[3134]
 abe @ /dev/pts/10: zsh[17212]
 abe @ /dev/pts/11: zsh[9274]
 abe @ /dev/pts/12: zsh[15317]
 abe @ /dev/pts/13: autossh[5455], ssh[5466], zsh[20256]
 abe @ /dev/pts/14: zsh[23167]
 abe @ /dev/pts/15: i3lock[6471,6472], zsh[30281]
 abe @ /dev/pts/17: zsh[9316]
 abe @ /dev/pts/19: less[925,6359,28543,29138], mupdf-x11[30942,31981], zsh[936]
 abe @ /dev/pts/2: zsh[4359]
 abe @ /dev/pts/20: zsh[15549]
 abe @ /dev/pts/21: zsh[13705]
 abe @ /dev/pts/22: zsh[10010]
 abe @ /dev/pts/24: zsh[29046]
 abe @ /dev/pts/25: zsh[12477]
 abe @ /dev/pts/27: zsh[8130]
 abe @ /dev/pts/3: ccze[6818], tail[6817], zsh[5301]
 abe @ /dev/pts/30: zsh[5510]
 abe @ /dev/pts/31: zsh[14587]
 abe @ /dev/pts/34: zsh[19960]
 abe @ /dev/pts/35: zsh[30555]
 abe @ /dev/pts/36: zsh[21324]
 abe @ /dev/pts/37: 

Bug#721617: [liblo] Bug#721617: pyliblo: FTBFS on sparc: testSendOthers (unit.ServerTestCase) ... Bus error (core dumped)

[Stephen Sinclair]

On Wed, Jun 1, 2016 at 2:48 AM, John Paul Adrian Glaubitz
 wrote:
> Control: reopen -1
> Control: severity -1 normal
>
>> Closing because liblo is no longer in sparc, and will not be built again 
>> there.
>
> Re-opening because in Debian we don't "fix bugs" by sweeping them under the
> carpet. Also, we're currently making sparc64 fit for release and there is
> a very active upstream.

That's a good attitude, currently I don't know anyone using sparc64
with liblo nor do I have access to such a machine, so reproducing and
testing, and therefore fixing, this bug is not possible for me.  So, I
look forward to your contribution.

>> It appears the problem is that in sparc, you can't just say
>> *(datatype*)data. Depending on datatype, 'data' has to be aligned at a
>> certain number of bytes from the original block (4 for int, 8 for
>> int64):
>
> Which is absolutely not specific to SPARC. The moment you are recasting
> a pointer that way, you are leaving the territory of the C99 specification
> which explicitly states that declarations which refer to the same object must
> have compatible types, otherwise the behavior is undefined (C99, 6.2.7/2) [1].

It is a good point.  If you have some examples where this fails it
would be a good contribution to our unit testing.  (testlo.c)

At the moment no one has actually complained about this bug, and
therefore I can only assume it has not actually been encountered and
remains an entirely theoretical bug, but I do welcome ideas for how to
fix it nonetheless, because compatibility with future architectures is
certainly a desirable goal.

> The code in question is therefore buggy and has to be fixed anyway as there
> is otherwise no guarantee it will work on future architectures or compilers.
>
> I'll have a look at this issue, it's a common programming mistake.

Unfortunately one that seems to be baked into the liblo API, but
perhaps there is a way to fix it without sacrificing efficiency, at
least on unaffected architectures.

If not, perhaps it can be fixed in a future API-breaking version of
liblo.  Proposals welcome.

Steve

Bug#824450: scanbd does not find scanner

[Chris Laif]

Hi Rolf.

On Wed, Jun 1, 2016 at 3:22 PM, Rolf Leggewie
 wrote:
>>> Do you know how to compile software on your own?
>>>
>> Yes, standard procedures shouldn't be a problem. You can even contact
>> me via private mail if that helps.
>
> Please try http://oss.leggewie.org/scanbd/scanbd_1.4.4-1rl1.dsc
>

Please see below.

> There are binary packages in that directory as well, but they are for
> i386.  I added a bunch of tests for common configuration mistakes into
> the latest init script.  Unfortunately, those didn't make it in time for
> jessie.  Before changing the binary packages, try to replace
> /etc/init.d/scanbd with the latest version from git
> http://anonscm.debian.org/cgit/collab-maint/scanbd.git/plain/debian/scanbd.init
> It might be enough to inform you where your configuration is wrong.  Do
> "/etc/init.d/scanbd status" and "/etc/init.d/scanbd restart" as root to
> see you where you stand.  I am almost certain your problem is not a true
> bug but a configuration mistake.
>

Changing the init script did not help. The scanner does not get
recognized and status/restart do not show any errors or any other
useful info. I strongly believe there is no configuration mistake
because I did not change the dist config files at all (only
debug-level = 7).

After that I compiled scanbd_1.4.4-1rl1 and ... voila, it works :)

Jun  1 23:36:37 scanbd: /usr/sbin/scanbd: SANE_CONFIG_DIR=/etc/scanbd
Jun  1 23:36:37 scanbd: /usr/sbin/scanbd: sane version 1.0
Jun  1 23:36:37 scanbd: /usr/sbin/scanbd: Scanning for local-only devices
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: found device:
plustek:libusb:007:027 Canon CanoScan N1240U/LiDE30 flatbed scanner
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: start_sane_threads
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: Starting poll thread for
plustek:libusb:007:027
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: Thread started for device
plustek:libusb:007:027
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: start dbus thread
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: sane_poll
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: Not Primary Owner (-1)
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: Name Error (Connection
":1.71" is not allowed to own the service "de.kmux.scanbd.server" due
to securit
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: udev init
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: get udev monitor
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: udev fd is non-blocking, now
setting to blocking mode
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: start udev thread
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: udev thread started
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: found 45 options for device
plustek:libusb:007:027
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: sane_find_matching_options
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: found 5 actions in section (null)
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: checking action scan with
filter: ^scan.*
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: found active option[2] mode
(type: 3) for device plustek:libusb:007:027
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: found active option[3] depth
(type: 1) for device plustek:libusb:007:027
Jun  1 23:36:41 scanbd: /usr/sbin/scanbd: found active option[5]
resolution (type: 1) for device plustek:libusb:007:027
[...]
Jun  1 23:46:45 scanbd: /usr/sbin/scanbd: checking option preview
number 6 (0) for device plustek:libusb:007:027: value: 0
Jun  1 23:46:45 scanbd: /usr/sbin/scanbd: polling thread for
plustek:libusb:007:027 cancellation point
Jun  1 23:46:45 scanbd: /usr/sbin/scanbd: polling device plustek:libusb:007:027
[...]

I did not test any scan functions yet, but I hope everything works
well when the scanner shows up in the log file.

I also double-checked by re-installing scanbd_jessiedist again: does
not work. Re-installing scanbd_1.4.4-1rl1: works.

Chris

Bug#822612: python3-pyatspi: depends on libatk-adaptor and libgail-common

[Emilio Pozuelo Monfort]

On 01/06/16 23:34, Samuel Thibault wrote:
> Hello,
> 
> Emilio Pozuelo Monfort, on Wed 01 Jun 2016 23:25:51 +0200, wrote:
>> On 26/04/16 02:07, Samuel Thibault wrote:
>>> Emilio Pozuelo Monfort, on Mon 25 Apr 2016 17:48:02 +0200, wrote:
 Do you think demoting libgail-common and libatk-adaptor to Recommends would
 be fine at this stage, so that they are installed by default but can be
 removed if desired (e.g. if/when there are no gtk2 apps installed)?
>>>
>>> That's a possibility. But we can also do like for qt4: since
>>> accessibility is now supposed to be enabled by default, we could
>>> make libgtk2.0-0 itself depend on libgail-common, i.e. the toolkit
>>> itself makes sure it has the tools to make itself accessible.  That
>>> way, libgail-common will get installed whenever a gtk2 application is
>>> installed for some reason.
>>
>> I'd like that. However that creates a dependency loop as libgail-common 
>> depends
>> on libgail18 which depends on libgtk2.0-0.
>>
>> Folding libgail into libgtk isn't an option as they don't necessarily keep 
>> the
>> same soname.
>>
>> Any ideas?
> 
> In the Qt4 case, we used a Recommends.  Here libgtk2.0-0 would recommend
> libgail-common.

Oh, sure, that sounds good. I'm busy this week but we'll try to look at it when
I have time (probably not until next week).

Cheers,
Emilio

Bug#826051: dh-lua: please sort version numbers in control file

[Reiner Herrmann]

Source: dh-lua
Version: 23
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that dh-lua inserts a Lua-Versions field into the control file, with
unsorted version numbers.

The attached patch fixes this by sorting the list of files used for
determining the versions.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/make/dh-lua.Makefile.multiple b/make/dh-lua.Makefile.multiple
index 156d00e..260c8b7 100644
--- a/make/dh-lua.Makefile.multiple
+++ b/make/dh-lua.Makefile.multiple
@@ -2,7 +2,7 @@
 # License: MIT/X
 # vim: ft=make
 
-MODULES=$(wildcard debian/*dh-lua.conf)
+MODULES=$(sort $(wildcard debian/*dh-lua.conf))
 LUA_SINGLE_MAKEFILE=/usr/share/dh-lua/make/dh-lua.Makefile.single
 H=@
 


signature.asc
Description: PGP signature

Bug#826000: ifupdown: if-pre-up.d and if-up.d scripts are run twice at boot

[Guus Sliepen]

retitle 826000 ifupdown: clarify that if-*.d scripts are run once extra with 
"IFACE=--all" when doing ifup -a
severity 826000 minor
thanks

On Wed, Jun 01, 2016 at 11:20:11PM +0200, Vincent Lefevre wrote:

> > > This means that various ifup scripts are probably buggy.
> > 
> > What makes you think that?
> 
> Various scripts (like mine) have:
> 
> [ "$IFACE" != "lo" ] || exit 0
> 
> without testing "$IFACE" != "--all" or testing $ADDRFAM = "meta".
> 
> An example is avahi-autoipd, which has:
> 
> [ "$IFACE" != "lo" ] || exit 0
> 
> then later:
> 
> /bin/ip route add 169.254.0.0/16 dev $IFACE metric 1000 scope link

You're skipping over the check for METHOD, which is set to "none" when
IFACE is "--all":

case "$METHOD" in
static|dhcp|NetworkManager) ;;
*) exit 0 ;;
esac

But if I have some time I'll go through other package's scripts and see
if any of them are missing some checks. But in any case, this is not a
bug in ifupdown.

> > > Also, why doesn't ifup write a log message about --all?
> > 
> > So far there was no reason for it.
> 
> It would be better to know what's going on. There's a log message
> for real interfaces. For the same reason, one could expect one for
> --all.
> 
> Moreover, the interfaces(5) man page says:
> 
>IFACE  physical name of the interface being processed
> 
> This is obviously wrong when IFACE is set to "--all".

The text about IFACE being set to "--all" is two paragraphs down. But
I'll clarify the manpage in the next release, and see about adding a log
message when the scripts for --all are being run.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#825962: libreoffice: crashes when trying to get the python macro menu if uno-0.3.3 has been installed with pip

[Florian]

Hi Rene,

You're right, it seems that I have made a little confusion here.

> Depends. That uno there seems like
> https://www.versioneye.com/python
/uno/0.3.3, is it?
Indeed.
When using pip3 install uno, it gets installed
in /usr/local/lib/pyton3.5/dist-packages/uno.

Has nothing to do with /usr/lib/python3/dist-packages/uno.py, which seems to 
contain the libreoffice stuff.

Well, whatever the uno 0.3.3 module is made for, it still causes
libreoffice to crash when installed, so maybe libreoffice gets confused
by the names too ;)

Regards,


On Tue, 31 May 2016 21:28:18 +0200 Rene Engelhard 
wrote:
> On Tue, May 31, 2016 at 09:11:37PM +0200, Florian Chaix wrote:
> > The bug only happens if uno-0.3.3 has been installed via "pip3
install uno" command.
> > Removing uno-0.3.3 using "pip3 uninstall uno" solves the issue.
> 
> Mmh.
> 
> > I guess installing uno via pip was not very smart in the first
place, given that debian package python3-uno exists, but maybe it
shouldn't make the whole app to crash.
> 
> Depends. That uno there seems like
> https://www.versioneye.com/python/uno/0.3.3, is it?
> (which has nothing to do with python3-uno, really.)
> 
> Regards,
> 
> Reme
> 
> > Florian.
> > 
> > 
> > -- System Information:
> > Debian Release: stretch/sid
> >   APT prefers testing
> >   APT policy: (900, 'testing'), (800, 'unstable')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > 
> > Versions of packages libreoffice depends on:
> > ii  dpkg   1.18.7
> > ii  fonts-dejavu   2.35-1
> > ii  fonts-sil-gentium-basic1.1-7
> > ii  libreoffice-avmedia-backend-gstreamer  1:5.1.3-1
> > ii  libreoffice-base   1:5.1.3-1
> > ii  libreoffice-calc   1:5.1.3-1
> > ii  libreoffice-core   1:5.1.3-1
> > ii  libreoffice-draw   1:5.1.3-1
> > ii  libreoffice-impress1:5.1.3-1
> > ii  libreoffice-java-common1:5.1.3-1
> > ii  libreoffice-math   1:5.1.3-1
> > ii  libreoffice-report-builder-bin 1:5.1.3-1
> > ii  libreoffice-writer 1:5.1.3-1
> > ii  python3-uno1:5.1.3-1
> > 
> > Versions of packages libreoffice recommends:
> > ii  fonts-liberation  1.07.4-1
> > ii  libpaper-utils1.1.24+nmu4
> > 
> > Versions of packages libreoffice suggests:
> > ii  cups-bsd2.1.3-5
> > ii  default-jre [java5-runtime] 2:1.8-57
> > ii  gstreamer1.0-libav  1.8.1-1
> > ii  gstreamer1.0-plugins-bad1.8.1-2
> > ii  gstreamer1.0-plugins-base   1.8.1-1
> > ii  gstreamer1.0-plugins-good   1.8.1-1
> > ii  gstreamer1.0-plugins-ugly   1.8.1-1
> > ii  hunspell-en-us [hunspell-dictionary]20070829-6
> > ii  hunspell-fr-classical [hunspell-dictionary] 1:5.6-1

Bug#826043: apt: gpg validation fails on hurd

[Samuel Thibault]

Adam Borowski, on Wed 01 Jun 2016 21:50:50 +0200, wrote:
> Despite all the relevant keys being installed (debian-archive-keyring,
> debian-ports-archive-keyring; "apt-key list" says they're there), I get:
> 
> W: GPG error: http://ftp.ports.debian.org/debian-ports unreleased InRelease:
> The following signatures couldn't be verified because the public key is not
> available: NO_PUBKEY B4C86482705A2CE1
> W: The repository 'http://ftp.debian-ports.org/debian unreleased InRelease'
> is not signed.
> W: GPG error: http://ftp.pl.debian.org/debian sid InRelease: The following
> signatures couldn't be verified because the public key is not available:
> NO_PUBKEY 8B48AD6246925553  NO_PUBKEY 7638D0442B90D010
> W: The repository 'http://ftp.pl.debian.org/debian sid InRelease' is not
> signed.

I managed to reproduce the issue indeed.

apt-get install --reinstall debian-archive-keyring

didn't fix it.

dpkg --force-depends -P debian-archive-keyring
dpkg -i /var/cache/apt/archives/debian-archive-keyring*

did fix it.

Samuel

Bug#826048: [Debian-med-packaging] Bug#826048: Faulty CMake file impairs compiling against GDCM

[Gert Wollny]

Control: tags -1 wontfix 

Hello Peter, 

Am Mittwoch, den 01.06.2016, 22:49 +0200 schrieb Peter Mattern:
> Source: gdcm
> Version: 2.6.3-{6,5}
> Severity: important
> 
> Compiling recent Ginkgo CADx against GDCM on Debian stretch yields
> two cmake warnings which
> suggest there are corresponding errors in the packaging of GDCM.
> 
> > 
> > -- The imported target "vtkgdcmsharpglue" references the file
> >   "/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"
> > but this file does not exist.  Possible reasons include:
> > 
> > 

This is to be expected. The problem is that gdcm references all
libraries within this cmake file, also those that may not be needed to
compile and link a program - e.g. Ginkgo doesn't need sharp or java
bindings related libraries. 

> The reason to assume it's a packaging issue in Debian is the fact
> that the warning messages can not be seen when the same Ginkgo CADx
> checkout gets compiled against the same GDCM version on Arch Linux
> where packaging does not involve any tweaking of GDCM's paths.

AFAIK unlike in Debian, where we separate the original software into
different packages like -dev, -java, -cli, Arch Linux only provides one
package that contains everything that is build. Therefore, if something
is referenced in the according CMake file, then it is also installed. 

Since in Debian the libraries are separated into different packages one
solution to get cmake run without warnings would be to split the cmake-
targets file accordingly, and the other would be to always pull in all
library packages with the -dev package. The first one is an upstream
decision. We could do the latter, but usually this doesn't make much
sense, because for using GDCM with Java, Mono, or Python the -dev
package is not needed, and for compiling C++ code against GDCM the
language bindings are not needed. 

> Just saying as I'm not sure whether it's alright to not have those
> files at hand by default.
It is completely alright as long as the dependent package does not
FTBFS. In fact you will see similar messages by other packages that use
CMake as build tool and provide these *target.cmake files (e.g. VTK).


Best, 
Gert

PS: I leave this open as wontfix because it is a common gotcha that
other might stumble upon. 

 

Bug#822612: python3-pyatspi: depends on libatk-adaptor and libgail-common

[Samuel Thibault]

Hello,

Emilio Pozuelo Monfort, on Wed 01 Jun 2016 23:25:51 +0200, wrote:
> On 26/04/16 02:07, Samuel Thibault wrote:
> > Emilio Pozuelo Monfort, on Mon 25 Apr 2016 17:48:02 +0200, wrote:
> >> Do you think demoting libgail-common and libatk-adaptor to Recommends would
> >> be fine at this stage, so that they are installed by default but can be
> >> removed if desired (e.g. if/when there are no gtk2 apps installed)?
> > 
> > That's a possibility. But we can also do like for qt4: since
> > accessibility is now supposed to be enabled by default, we could
> > make libgtk2.0-0 itself depend on libgail-common, i.e. the toolkit
> > itself makes sure it has the tools to make itself accessible.  That
> > way, libgail-common will get installed whenever a gtk2 application is
> > installed for some reason.
> 
> I'd like that. However that creates a dependency loop as libgail-common 
> depends
> on libgail18 which depends on libgtk2.0-0.
> 
> Folding libgail into libgtk isn't an option as they don't necessarily keep the
> same soname.
> 
> Any ideas?

In the Qt4 case, we used a Recommends.  Here libgtk2.0-0 would recommend
libgail-common.

Samuel

Bug#822494: Time to remove? Unusable since 2014.

[Eric Beuque]

Hi, we are updating upstream package in debian, just waiting for some
review before to send it to debian repository.

It will be soon avaliable.

2016-06-01 23:13 GMT+02:00 Petter Reinholdtsen :

> When deciding if the package should be kept or not, it might be useful to
> note that there is recent developments in the new upstream git repository
> mentioned in bug #813192.  In other words, the upstream developer is still
> active,
> even if no update has been done to the Debian package since 2014.
>
> I do not use this package myself, but have it installed and noticed its
> removal
> from testing thanks to how-can-i-help and decided to check it out.   It
> seem like
> a good platform for making the TV channel I am involed in (Frikanalen)
> easily
> available for Debian users.
> --
> Happy hacking
> Petter Reinholdtsen
>
>

Bug#826050: Faulty CMake file impairs compiling against VTK

[Peter Mattern]

Source: vtk6
Version: 6.3.0+dfsg1-1, 6.2.0+dfsg1-11.1
Severity: important

Compiling recent Ginkgo CADx against VTK on Debian testing yields two cmake 
warnings which
suggest there are corresponding errors in the packaging of VTK.

> -- The imported target "vtkRenderingPythonTkWidgets" references the file
>"/usr/lib/x86_64-linux-gnu/libvtkRenderingPythonTkWidgets.so"
> but this file does not exist.  Possible reasons include:
> * The file was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and contained
>"/usr/lib/cmake/vtk-6.2/VTKTargets.cmake"
> but not all the files it references.

A library libvtkRenderingPythonTkWidgets.so was provided by package libvtk6-dev 
in jessie
(VTK 6.1) but no longer exists as of stretch (VTK 6.2). The library does still 
exist in more
recent versions of VTK as can be seen with VTK 7.0.0 on Arch Linux, 6.3 on Arch 
Linux or
openSUSE Leap 42.1 and 6.2 on Fedora 23. In all these distributions the naming 
is the
typical libvtkRenderingPythonTkWidgets*-*.so that VTK upstream is 
using to name
the third-party libraries imported into the VTK source tree, though.

> -- The imported target "vtk" references the file
>"/usr/bin/vtk"
> but this file does not exist.  Possible reasons include:
> * The file was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and contained
>"/usr/lib/cmake/vtk-6.2/VTKTargets.cmake"
> but not all the files it references.

A binary /usr/bin/vtk is provided by package tcl-vtk in jessie but is no longer 
available in
stretch. Package vtk6 in both stretch and jessie is providing a binary 
/usr/bin/vtk6 only.

All findings are the same when the VTK binary packages of testing are replaced 
with their
counterparts from sid plus their additional new or changed dependencies.

The reason to assume it's a packaging issue in Debian is the fact that the 
warning messages
can not be seen when the same Ginkgo CADx checkout gets compiled against the 
same VTK version
on Arch Linux where packaging does not involve any tweaking of VTK's paths.

On a side note I'm wondering whether it's on purpose that packages 
libvtk6.3[-qt] as well as
libvtk6.2[-qt] are stated as belonging to source package vtk6 (6.3) of sid at
https://packages.debian.org/source/sid/vtk6.

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

Kernel: Linux 4.5.0-2-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)

-- no debconf information

Bug#810392: 0xffff: please switch to libusb 1.0

[Pali Rohár]

On Thursday 28 April 2016 10:13:51 Pali Rohár wrote:
> On Tuesday 15 March 2016 22:12:18 Aurelien Jarno wrote:
> > On 2016-03-15 21:26, Pali Rohár wrote:
> > > Aurelien, I would suggest to have libusb-dev (libusb 0.1) package
> > > in Debian repository, because it is stable and is working, not
> > > like new libusb-1.0-0-dev which is slow and unusable.
> > 
> > I disagree with this statement, libusb 1.0 is used in many
> > applications without any problem. Contrary to libusb 0.1, it is a
> > maintained library, so if you encountered any bug that makes it
> > slow, unusable or whatever, please report a bug and a testcase, I
> > am sure we'll find a solution.
> 
> Looks like upstream ignores this problem and so there is no other way
> as using working libusb 0.1 library instead that new libusb 1.0
> which does not work...

Ok, upstream is definitely ignoring this problem... I got no response 
about it for 3 months!

I really suggest to stay on libusb 0.1 library which is *working* and 
not forcing us to use non working slow and buggy version 1.0.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#822612: python3-pyatspi: depends on libatk-adaptor and libgail-common

[Emilio Pozuelo Monfort]

On 26/04/16 02:07, Samuel Thibault wrote:
> Hello,
> 
> Emilio Pozuelo Monfort, on Mon 25 Apr 2016 17:48:02 +0200, wrote:
>> Do you think demoting libgail-common and libatk-adaptor to Recommends would
>> be fine at this stage, so that they are installed by default but can be
>> removed if desired (e.g. if/when there are no gtk2 apps installed)?
> 
> That's a possibility. But we can also do like for qt4: since
> accessibility is now supposed to be enabled by default, we could
> make libgtk2.0-0 itself depend on libgail-common, i.e. the toolkit
> itself makes sure it has the tools to make itself accessible.  That
> way, libgail-common will get installed whenever a gtk2 application is
> installed for some reason.

I'd like that. However that creates a dependency loop as libgail-common depends
on libgail18 which depends on libgtk2.0-0.

Folding libgail into libgtk isn't an option as they don't necessarily keep the
same soname.

Any ideas?

>> These pull libatk-bridge and libgail-common, which depend on
>> libgail18, which depends on libgtk2.0-0.
> 
> Libatk-bridge doesn't actually depend on libgail18, so we can remove its
> dependency on libgail-common, provided that libgtk2.0-0 depends on it.

OK.

Cheers,
Emilio

Bug#825394: systemd kills background processes after user logs out

[Jonathan de Boyne Pollard]

Martin Pitt:
> The option has already be reverted in the packaging git.
> This isn't an exercise in "who shouts the loudest".

It should, however, be an exercise in fixing bugs properly.  (-:

Turning off the enabling flag doesn't fix the underlying flawed 
mechanism.  There is still a logind bug to be fixed.


logind has invented its own systemd login session mechanism (as a "scope 
unit") .  It adds processes to a systemd login session. There's a moral 
equivalent of session leadership.  Systemd login sessions close.  At 
session closure, other processes in the session are sent a signal.  So 
far, this is reinventing the kernel's login session concept (as 
augmented by some job control shells) quite straightforwardly.


The bug is a very simple one.  systemd *sends the wrong signal* when it 
is decided that the session is closing.  It should send SIGHUP. It 
instead sends SIGTERM and then sends SIGKILL.  However, logind is the 
locus of the bug because it is logind that is constructing the login 
session and instructing systemd what to do, via the internal systemd 
Desktop Bus protocol.  It's as simple as that.


Send SIGHUP instead of SIGTERM+SIGKILL at systemd login session closure, 
and systemd and logind will continue to interoperate with wget, deluged, 
mosh-server, emacs --daemon, screen, tmux, and all of the rest — 
including anything invoked via nohup.  The DBUS server programs (in 
Freedesktop bug #94508) that are staying alive in the systemd login 
session because of a circular dependency receive a SIGHUP, which 
terminates them and breaks the circle.  The programs (in this bug and 
bug #825941) that have masked/ignored SIGHUP, because that's been the 
protocol for the past 37 years or more (since 7th Edition at minimum), 
avoid termination as they desire.


There are two ways to fix this that I can see.

The first way is to fix the systemd login session so that systemd 
terminates it with SIGHUP.  systemd is told what the "stop" action is 
for the session by logind.  At the moment, in your manager_start_scope() 
function, logind is creating the systemd login session with the 
equivalent of


>KillSignal=SIGTERM
>SendSIGHUP=yes
>SendSIGKILL=yes

Modify that function to instead use the equivalent of

>KillSignal=SIGHUP
>SendSIGHUP=yes
>SendSIGKILL=no

This is an inferior route, in my view, to the second way of doing this.  
The second way of doing this is for logind not to try to *stop* the 
login session in the first place.  Leave that to system shutdown and 
suchlike, which can use "StopUnit" and the resultant SIGTERMs+SIGKILLs 
in circumstances where those are actually appropriate even to nohupped 
processes.  Rather, modify your session_stop_scope() function to call a 
new manager_hangup_scope() function, which invokes "KillUnit" on the 
login session with a kill-who of "all" and a kill-signal of SIGHUP.

Bug#826000: ifupdown: if-pre-up.d and if-up.d scripts are run twice at boot

[Vincent Lefevre]

On 2016-06-01 21:49:44 +0200, Guus Sliepen wrote:
> On Wed, Jun 01, 2016 at 09:06:20PM +0200, Vincent Lefevre wrote:
> > This means that various ifup scripts are probably buggy.
> 
> What makes you think that?

Various scripts (like mine) have:

[ "$IFACE" != "lo" ] || exit 0

without testing "$IFACE" != "--all" or testing $ADDRFAM = "meta".

An example is avahi-autoipd, which has:

[ "$IFACE" != "lo" ] || exit 0

then later:

/bin/ip route add 169.254.0.0/16 dev $IFACE metric 1000 scope link

Note that $IFACE is expected here to be an interface, not --all!

> According to what you said earlier, it was hanging in z_home_net,
> which is not in any official Debian package, so I assume this script
> was written by you?

Yes.

> I haven't heard any reports of other scripts breaking, and ifupdown
> has been calling the scripts with IFACE="--all" since early 2012.

The breakage may be silent.

> > Also, why doesn't ifup write a log message about --all?
> 
> So far there was no reason for it.

It would be better to know what's going on. There's a log message
for real interfaces. For the same reason, one could expect one for
--all.

Moreover, the interfaces(5) man page says:

   IFACE  physical name of the interface being processed

This is obviously wrong when IFACE is set to "--all".

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

Bug#826049: kodi: No music visualizations

[Wendigo]

Package: kodi
Version: 16.1+dfsg1-1~bpo8+2
Severity: normal

Dear Maintainer,

In you install Kodi 16.1 from backports music visualizations don't work 
anymore. 
I think in others distros you're supposed now to install a visualizations 
package.
There is no visualizations package in backports.
Cheers


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 8.4
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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 kodi depends on:
ii  kodi-bin   16.1+dfsg1-1~bpo8+2
ii  kodi-data  16.1+dfsg1-1~bpo8+2

kodi recommends no packages.

kodi suggests no packages.

-- no debconf information

Bug#822604: scanmem: depends on gksu which is deprecated

[Emilio Pozuelo Monfort]

Hi Sebastian, sorry for the huge delay.

On 28/04/16 01:59, Sebastian Parschauer wrote:
> On 25.04.2016 17:58, Emilio Pozuelo Monfort wrote:
>>> My plan is to become the new Debian scanmem package maintainer and to
>>> provide latest versions myself.
>>>
>>> I already started with a packaging repo at:
>>> https://github.com/sriemer/scanmem-debian
>>>
>>> I need supporters for this plan. Updating is the better choice IMHO.
>>>
>>> Can I count on your support?
>>>
>>> If yes, then I'll prepare the new package and send it to you for review.
>>
>> Yes, please send me a link to a .dsc when ready and I'll have a look.
> 
> Hi Emilio,
> 
> I'm ready. I've released and picked upstream version v0.15.7 as it
> contains quite important security fixes found by Coverity and a security
> researcher. So we'll jump from 0.13-1 to 0.15.7-1.
> 
> I've prepared the new Debian packaging commits here:
> 
> https://github.com/sriemer/scanmem-debian/commits/master
> 
> Then I've gathered and extracted the upstream tarball and run
> 'debuild -S' to provide the .dsc file to you:
> 
> https://github.com/sriemer/scanmem-debian/tree/source
> 
> I've built this for "testing" and "unstable" for i386 and amd64 in local
> sbuild environments in the branches "unstable-amd64", "unstable-i386",
> "testing-amd64" and "testing-i386".
> 
> Lintian is only still warning about the fact that libscanmem is not
> provided in a separate package. It is only there for better backend
> communication for GameConqueror. So this can be ignored.

Hmm. If that's the case, you shouldn't install the libscanmem.so symlink. I see
you use it for dlopening the lib in gameconqueror, but that could happen by
dlopening libscanmem.so.1. Also, it would be better if the library was installed
into a /usr/lib/scanmem/ directory (or similar) so it wasn't on the default
library search path. Though I don't think that's strictly necessary.

gameconqueror depends on scanmem (>= 0.15.7). What prevents scanmem from being
upgraded to, say, 0.16, where libscanmem has changed incompatibly, while
gameconqueror stays at 0.15.7? You should probably add a strict versioning.

Other than that things look good.

> I've tested scanmem and GC in fresh Debian "testing" VMs for amd64 and
> i386 with GNOME and MATE for now. All the upstream test cases have been
> passed. The packages are working like a charm and as expected. :-) No
> files are missing in the .deb packages and the GC icon is visible right
> away after installation. :-)

Good.

> This is done. Please use the "source" branch, build the packages from
> there and upload the new version.

I'll upload as soon as those comments are addressed.

Cheers,
Emilio

Bug#822494: Time to remove? Unusable since 2014.

[Petter Reinholdtsen]

When deciding if the package should be kept or not, it might be useful to
note that there is recent developments in the new upstream git repository
mentioned in bug #813192.  In other words, the upstream developer is still 
active,
even if no update has been done to the Debian package since 2014.

I do not use this package myself, but have it installed and noticed its removal
from testing thanks to how-can-i-help and decided to check it out.   It seem 
like
a good platform for making the TV channel I am involed in (Frikanalen) easily
available for Debian users.
-- 
Happy hacking
Petter Reinholdtsen

Bug#826045: systemd: New kernels are not booted

[Martin Pitt]

Control: tag -1 help

Michael Biebl [2016-06-01 22:39 +0200]:
> systemd-boot is not officially supported yet.
> We install the systemd-boot related files so users can play with them,
> but you are basically on your own.
> 
> Maybe it's better to remove them.
> 
> Martin, your thoughts?

If someone wants to adopt systemd-boot, I'd be glad to review patches
(e. g. Julien seemed to be interested in this the other day).
Otherwise, if nobody wants to maintain this, I agree that we better
remove it, as shipping incomplete features will continue to cause bugs
like this.

Martin

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


signature.asc
Description: PGP signature

Bug#826048: Faulty CMake file impairs compiling against GDCM

[Peter Mattern]

Source: gdcm
Version: 2.6.3-{6,5}
Severity: important

Compiling recent Ginkgo CADx against GDCM on Debian stretch yields two cmake 
warnings which
suggest there are corresponding errors in the packaging of GDCM.

> -- The imported target "vtkgdcmsharpglue" references the file
>   "/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"
> but this file does not exist.  Possible reasons include:
> * The file was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and contained
>   "/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
>   but not all the files it references.

libvtkgdcmsharpglue.so is provided by package libvtkgdcm-cil but placed in
/usr/lib/cli/vtkgdcm-sharp-2.6/.

> -- The imported target "vtkgdcmPython" references the file
>   "/usr/lib/python/dist-packages/libvtkgdcmPython.so"
> but this file does not exist.  Possible reasons include:
> * The file was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and contained
>   "/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
>   but not all the files it references.

libvtkgdcmPython.so isn't available any longer in stretch. It used to be 
provided in jessie
(GDCM 2.4.4) by package python-vtkgdcm in /usr/lib/python2.7/dist-packages/ 
where a library
libvtkgdcmPython.x86_64-linux-gnu.so can be found in stretch right now.

All findings are the same when the GDCM binary packages of stretch are replaced 
with their
counterparts from sid plus their additional new or changed dependencies.

The reason to assume it's a packaging issue in Debian is the fact that the 
warning messages
can not be seen when the same Ginkgo CADx checkout gets compiled against the 
same GDCM version
on Arch Linux where packaging does not involve any tweaking of GDCM's paths.

On a side note there's by default a bunch of similar messages, see attached 
ginkgo-vs-gdcm_cmake.txt,
which are simply due to the packages providing the missing files - 
libvtkgdcm2.6,
libvtkgdcm-java, python-vtkgdcm and libgdcm-tools - not being installed.
Just saying as I'm not sure whether it's alright to not have those files at 
hand by default.

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

Kernel: Linux 4.5.0-2-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)
-- The imported target "vtkgdcm" references the file
  "/usr/lib/x86_64-linux-gnu/libvtkgdcm.so.2.6.3"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
  "/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
  but not all the files it references.

-- The imported target "vtkgdcmJava" references the file
  "/usr/lib/x86_64-linux-gnu/jni/libvtkgdcmJava.so"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
  "/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
  but not all the files it references.

-- The imported target "vtkgdcmPythonD" references the file
  "/usr/lib/x86_64-linux-gnu/libvtkgdcmPythonD.so.2.6.3"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
  "/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
  but not all the files it references.

-- The imported target "gdcmdump" references the file
  "/usr/bin/gdcmdump"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
  "/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
  but not all the files it references.

-- The imported target "gdcmdiff" references the file
  "/usr/bin/gdcmdiff"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
  "/usr/lib/x86_64-linux-gnu/gdcm-2.6/GDCMTargets.cmake"
  but not all the files it references.

-- The imported target "gdcmraw" references the file
  "/usr/bin/gdcmraw"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or 

Bug#826047: plasma-desktop: depend on kactivitymanagerd as replacement for kactivities

[Martin Steigerwald]

Package: plasma-desktop
Version: 4:5.6.4-1
Severity: important

Dear Maxy,

please add a dependency to kactivitymanagerd here or whereever it is
suitable. Without it apt dist-upgrade to most recent state of Plasma /
KF5 from today removed kactivities without installing its replacement
package.

Then activity switcher, desktop backgrounds and stuff like this is not
working.

Thanks,
Martin

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

Kernel: Linux 4.6.0-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.6.4-1
ii  kde-cli-tools4:5.6.4-1
ii  kded55.22.0-1
ii  kio  5.22.0-1
ii  libc62.22-10
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.4
ii  libgcc1  1:6.1.1-4
ii  libkf5activities55.22.0-2
ii  libkf5activitiesexperimentalstats1   4:5.6.4-1
ii  libkf5archive5   5.22.0-1
ii  libkf5auth5  5.22.0-1
ii  libkf5baloo5 5.22.0-1
ii  libkf5bookmarks5 5.22.0-2
ii  libkf5codecs55.22.0-1
ii  libkf5completion55.22.0-1
ii  libkf5configcore55.22.0-1
ii  libkf5configgui5 5.22.0-1
ii  libkf5configwidgets5 5.22.0-1
ii  libkf5coreaddons55.22.0-1
ii  libkf5dbusaddons55.22.0-1
ii  libkf5emoticons-bin  5.22.0-1
ii  libkf5emoticons5 5.22.0-1
ii  libkf5globalaccel5   5.22.0-1
ii  libkf5guiaddons5 5.22.0-1
ii  libkf5i18n5  5.22.1-1
ii  libkf5iconthemes55.22.0-1
ii  libkf5itemmodels55.22.0-1
ii  libkf5itemviews5 5.22.0-1
ii  libkf5jobwidgets55.22.0-1
ii  libkf5kcmutils5  5.22.0-1
ii  libkf5kdelibs4support5   5.22.0-2
ii  libkf5kiocore5   5.22.0-1
ii  libkf5kiofilewidgets55.22.0-1
ii  libkf5kiowidgets55.22.0-1
ii  libkf5newstuff5  5.22.0-1
ii  libkf5notifications5 5.22.0-1
ii  libkf5notifyconfig5  5.22.0-1
ii  libkf5parts5 5.22.0-1
ii  libkf5people55.22.0-1
ii  libkf5peoplewidgets5 5.22.0-1
ii  libkf5plasma55.22.0-1
ii  libkf5plasmaquick5   5.22.0-1
ii  libkf5quickaddons5   5.22.0-1
ii  libkf5runner55.22.0-1
ii  libkf5service-bin5.22.0-1
ii  libkf5service5   5.22.0-1
ii  libkf5solid5 5.22.0-1
ii  libkf5sonnetui5  5.22.0-2
ii  libkf5wallet-bin 5.22.0-1
ii  libkf5wallet55.22.0-1
ii  libkf5widgetsaddons5 5.22.0-1
ii  libkf5windowsystem5  5.22.0-1
ii  libkf5xmlgui55.22.0-1
ii  libkfontinst54:5.6.4-1
ii  libkfontinstui5  4:5.6.4-1
ii  libkworkspace5-5 4:5.6.4-2
ii  libphonon4qt5-4  4:4.9.0-2
ii  libpulse-mainloop-glib0  8.0-2+b2
ii  libpulse08.0-2+b2
ii  libqt5concurrent55.5.1+dfsg-17
ii  libqt5core5a 5.5.1+dfsg-17
ii  libqt5dbus5  5.5.1+dfsg-17
ii  libqt5gui5   5.5.1+dfsg-17
ii  libqt5network5   5.5.1+dfsg-17
ii  libqt5printsupport5  5.5.1+dfsg-17
ii  libqt5qml5   5.5.1-3
ii  libqt5quick5 5.5.1-3
ii  libqt5quickwidgets5  5.5.1-3
ii  libqt5sql5   5.5.1+dfsg-17
ii  libqt5svg5   5.5.1-2
ii  libqt5widgets5   5.5.1+dfsg-17
ii  libqt5x11extras5 5.5.1-3
ii  libqt5xml5   5.5.1+dfsg-17
ii  libstdc++6   6.1.1-4
ii  libtaskmanager5  4:5.6.4-2
ii  libx11-6   

Bug#826045: systemd: New kernels are not booted

[Michael Biebl]

Control: severity -1 wishlist

Am 01.06.2016 um 22:25 schrieb Thomas Prokosch:
> After gummiboot has been integrated into systemd as systemd-boot, I
> decided to give this new feature a try and installed a new machine
> with systemd, not installing gummiboot or any other boot loader. The
> machine is capable of booting an UEFI stub, so systemd-boot should be
> able to handle this. However, with this approach the machine failed to
> boot. Only after manually copying the kernel and initramfs from /boot
> to /boot/efi, and manually setting up the relevant data structures in
> /boot/efi the machine came up as expected.
> 
> It seems that integrating gummiboot into systemd is missing a critical
> piece, that is the update-gummiboot script that copies the kernel
> files. This script was installed in the postinst hook for kernels at
> /etc/kernel/postinst.d/ but is absent in systemd.
> 
> Because of this omission new installs are broken, this is why I set
> the severy of this bug report to "important".
> 
> Please add an equivalent of the update-gummiboot script to systemd.

systemd-boot is not officially supported yet.
We install the systemd-boot related files so users can play with them,
but you are basically on your own.

Maybe it's better to remove them.

Martin, your thoughts?



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



signature.asc
Description: OpenPGP digital signature

Bug#826043: #826043: apt: gpg validation fails on hurd

[Adam Borowski]

22:27 < youpi> ah, indeed, that looks like a new issue, apparently with
   libc, possibly due to the recent revamp in libc nss

As manually calling "gpg --keyring /etc/apt/… --verify /var/lib/apt/…Release"
works, I'm not reassigning away from apt yet.  Both you and Samuel Thibault
(hurd porter) know it better than me.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#826021: more info

[Antoine Beaupré]

More improvements, including graphs from multiple machines, are detailed
here:

 https://anarc.at/blog/2016-06-01-work-volume/

-- 
By now the computer has moved out of the den and into the rest of your
life. It will consume all of your spare time, and even your vacation,
if you let it. It will empty your wallet and tie up your thoughts. It
will drive away your family. Your friends will start to think of you
as a bore. And what for?
   - The True Computerist by Tom Pittman

Bug#826044: needrestart: Hangs in apt hook with a zombie

[Thomas Liske]

Hi Axel,

could you please provide your needrestart config (if changed from
defaults)? Is the problem reproducable? Could you attach strace to
needrestart while it hangs?


TIA & HTH,
Thomas

On Wed, Jun 01, 2016 at 10:20:58PM +0200, Axel Beckert wrote:
> Package: needrestart
> Version: 2.8-1
> Severity: important
> 
> Dear Maintainer,
> 
> after this evening's package upgraee run, needrestart did no more exit
> when running during the apt hook. htop shows a needrestart zombie
> process:
> 
>  5803 root   20   0 25776  4224  2092 S  0.0  0.0  4:40.53 `- SCREEN -RdU
>  8398 root   20   0 20408  3432  2800 S  0.0  0.0  0:00.10 |  `- /bin/bash
>  6327 root   20   0 20420  3460  2812 S  0.0  0.0  0:00.18 |  `- /bin/bash
>  6304 root   20   0 20408  3416  2780 S  0.0  0.0  0:00.10 |  `- /bin/bash
> 27888 root   20   0 25576  6124  2696 R  0.7  0.0  0:09.58 |  |  `- htop
>  5804 root   20   0 20404  3456  2824 S  0.0  0.0  0:00.28 |  `- /bin/bash
> 12196 root   20   0  598M  189M 45008 S  0.0  0.3  0:08.04 | `- 
> aptitude -u
> 24022 root   20   0  598M  146M  1056 S  0.0  0.2  0:00.00 |`- 
> aptitude -u
> 24160 root   20   0  4308   800   716 S  0.0  0.0  0:00.00 ||  `- 
> sh -c test -x /usr/lib/needrestart/apt-pinvoke && 
> /usr/lib/needrestart/apt-pinvoke || true
> 24161 root   20   0 60748 17904  4172 S  0.0  0.0  0:00.14 || 
> `- /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart
> 24169 root   20   0 0 0 0 Z  0.0  0.0  0:00.32 || 
>`- needrestart
> 12950 root   20   0  598M  189M 45008 S  0.0  0.3  0:00.03 |`- 
> aptitude -u 
> 
> -- Package-specific info:

> needrestart output:
> Your outdated processes:
> at-spi-bus-laun[4320], at-spi2-registr[4327], autocutsel[4157], autossh[5455, 
> 7277], ccze[7278,
>  6818], dbus-daemon[4119, 4325], dbus-launch[4118], dconf-service[5282], 
> emacs[19225],
>  gconfd-2[5169], gvfs-afc-volume[9291], gvfsd[4337], gvfsd-metadata[2930], 
> gvfs-goa-volume[9281],
>  gvfs-gphoto2-vo[9286], gvfs-mtp-volume[9276], gvfs-udisks2-vo[9270], 
> iceweasel[5134], i3[4090],
>  i3bar[23198], kded4[5223], kdeinit4[5218], keynav[4156], 
> kglobalaccel[23813], klauncher[5221],
>  knotify4[23815], kuiserver[2386], kwalletd[4348], kwalletd5[4344], 
> less[29138, 28543, 925, 6359],
>  liferea[5241], monkeysphere-va[4128], mupdf-x11[31981, 30942, 2413], 
> somethings.sh[7270],
>  qasmixer[4316], redshift[4332], redshift-gtk[4317], sh[19955, 29041, 17207, 
> 9311, 931, 9266,
>  23196, 10005, 15544, 5322, 5505, 5296, 21319, 23162, 15312, 7326, 4354, 
> 30550, 13700, 7300, 5386,
>  1777, 3129, 20251, 12472, 30276, 14582, 8125], smart-notifier[4296], 
> specto[9145], ssh[13024,
>  5466], tail[6817], unclutter[4125], .xsession[4312, 4313], xsettingsd[4440], 
> xterm[5297, 1778,
>  7301, 3130, 5387, 15313, 9267, 5323, 20252, 17208, 30277, 30551, 29042, 
> 8126, 12473, 15545, 14583,
>  10006, 9312, 5506, 7327, 21320, 13701, 23163, 19956, 932, 4355], 
> yeahconsole[4170], zsh[5391,
>  5327, 15549, 13705, 29046, 5510, 936, 8130, 4359, 1782, 9316, 5301, 14587, 
> 12477, 19960, 20256,
>  9274, 7305, 7331, 30555, 21324, 30281, 17212, 4193, 10010, 3134, 15317, 
> 23167]
> 
> checkrestart output:
> 

> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
> (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), 
> (1, 'buildd-experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.6.0-trunk-amd64 (SMP w/8 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages needrestart depends on:
> ii  dpkg   1.18.7
> ii  gettext-base   0.19.7-2
> ii  libintl-perl   1.24-1
> ii  libmodule-find-perl0.13-1
> ii  libmodule-scandeps-perl1.21-1
> ii  libproc-processtable-perl  0.53-1+b1
> ii  libsort-naturally-perl 1.03-1
> ii  libterm-readkey-perl   2.33-1+b1
> ii  perl   5.22.2-1
> ii  xz-utils   5.1.1alpha+20120614-2.1
> 
> needrestart recommends no packages.
> 
> Versions of packages needrestart suggests:
> ii  libnotify-bin0.7.6-2
> ii  needrestart-session  0.3-2
> 
> -- no debconf information

--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#826046: mono-runtime: sudoers, I cannot run the rutine. Appers my name is not in sudoers

[Jean Collard]

Package: mono-runtime
Version: 2.10.8.1-8+deb7u1
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

Kernel: Linux 3.4-9-rtai-686-pae (SMP w/1 CPU core; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mono-runtime depends on:
ii  libc6 2.13-38+deb7u11
ii  mono-gac  2.10.8.1-8+deb7u1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages mono-runtime recommends:
ii  binfmt-support  2.0.12

Versions of packages mono-runtime suggests:
ii  libgnome2-0  2.32.1-3
ii  xdg-utils1.1.0~rc1+git20111210-6+deb7u3

-- no debconf information

Bug#826045: systemd: New kernels are not booted

[Thomas Prokosch]

Package: systemd
Version: 229-6
Severity: important

After gummiboot has been integrated into systemd as systemd-boot, I
decided to give this new feature a try and installed a new machine
with systemd, not installing gummiboot or any other boot loader. The
machine is capable of booting an UEFI stub, so systemd-boot should be
able to handle this. However, with this approach the machine failed to
boot. Only after manually copying the kernel and initramfs from /boot
to /boot/efi, and manually setting up the relevant data structures in
/boot/efi the machine came up as expected.

It seems that integrating gummiboot into systemd is missing a critical
piece, that is the update-gummiboot script that copies the kernel
files. This script was installed in the postinst hook for kernels at
/etc/kernel/postinst.d/ but is absent in systemd.

Because of this omission new installs are broken, this is why I set
the severy of this bug report to "important".

Please add an equivalent of the update-gummiboot script to systemd.

br,
Thomas


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-2+b2
ii  libaudit1   1:2.4.5-1
ii  libblkid1   2.27.1-1
ii  libc6   2.22-7
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.4-4
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27.1-1
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.4-3
ii  libsystemd0 229-6
ii  mount   2.27.1-1
ii  sysv-rc 2.88dsf-59.2
ii  util-linux  2.27.1-1

Versions of packages systemd recommends:
ii  dbus1.10.8-1
ii  libpam-systemd  229-6

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  229-6

-- no debconf information

Bug#826044: needrestart: Hangs in apt hook with a zombie

[Axel Beckert]

Package: needrestart
Version: 2.8-1
Severity: important

Dear Maintainer,

after this evening's package upgraee run, needrestart did no more exit
when running during the apt hook. htop shows a needrestart zombie
process:

 5803 root   20   0 25776  4224  2092 S  0.0  0.0  4:40.53 `- SCREEN -RdU
 8398 root   20   0 20408  3432  2800 S  0.0  0.0  0:00.10 |  `- /bin/bash
 6327 root   20   0 20420  3460  2812 S  0.0  0.0  0:00.18 |  `- /bin/bash
 6304 root   20   0 20408  3416  2780 S  0.0  0.0  0:00.10 |  `- /bin/bash
27888 root   20   0 25576  6124  2696 R  0.7  0.0  0:09.58 |  |  `- htop
 5804 root   20   0 20404  3456  2824 S  0.0  0.0  0:00.28 |  `- /bin/bash
12196 root   20   0  598M  189M 45008 S  0.0  0.3  0:08.04 | `- 
aptitude -u
24022 root   20   0  598M  146M  1056 S  0.0  0.2  0:00.00 |`- 
aptitude -u
24160 root   20   0  4308   800   716 S  0.0  0.0  0:00.00 ||  `- 
sh -c test -x /usr/lib/needrestart/apt-pinvoke && 
/usr/lib/needrestart/apt-pinvoke || true
24161 root   20   0 60748 17904  4172 S  0.0  0.0  0:00.14 || 
`- /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart
24169 root   20   0 0 0 0 Z  0.0  0.0  0:00.32 ||   
 `- needrestart
12950 root   20   0  598M  189M 45008 S  0.0  0.3  0:00.03 |`- 
aptitude -u 

-- Package-specific info:
needrestart output:
Your outdated processes:
at-spi-bus-laun[4320], at-spi2-registr[4327], autocutsel[4157], autossh[5455, 
7277], ccze[7278,
 6818], dbus-daemon[4119, 4325], dbus-launch[4118], dconf-service[5282], 
emacs[19225],
 gconfd-2[5169], gvfs-afc-volume[9291], gvfsd[4337], gvfsd-metadata[2930], 
gvfs-goa-volume[9281],
 gvfs-gphoto2-vo[9286], gvfs-mtp-volume[9276], gvfs-udisks2-vo[9270], 
iceweasel[5134], i3[4090],
 i3bar[23198], kded4[5223], kdeinit4[5218], keynav[4156], kglobalaccel[23813], 
klauncher[5221],
 knotify4[23815], kuiserver[2386], kwalletd[4348], kwalletd5[4344], less[29138, 
28543, 925, 6359],
 liferea[5241], monkeysphere-va[4128], mupdf-x11[31981, 30942, 2413], 
somethings.sh[7270],
 qasmixer[4316], redshift[4332], redshift-gtk[4317], sh[19955, 29041, 17207, 
9311, 931, 9266,
 23196, 10005, 15544, 5322, 5505, 5296, 21319, 23162, 15312, 7326, 4354, 30550, 
13700, 7300, 5386,
 1777, 3129, 20251, 12472, 30276, 14582, 8125], smart-notifier[4296], 
specto[9145], ssh[13024,
 5466], tail[6817], unclutter[4125], .xsession[4312, 4313], xsettingsd[4440], 
xterm[5297, 1778,
 7301, 3130, 5387, 15313, 9267, 5323, 20252, 17208, 30277, 30551, 29042, 8126, 
12473, 15545, 14583,
 10006, 9312, 5506, 7327, 21320, 13701, 23163, 19956, 932, 4355], 
yeahconsole[4170], zsh[5391,
 5327, 15549, 13705, 29046, 5510, 936, 8130, 4359, 1782, 9316, 5301, 14587, 
12477, 19960, 20256,
 9274, 7305, 7331, 30555, 21324, 30281, 17212, 4193, 10010, 3134, 15317, 23167]

checkrestart output:


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

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

Versions of packages needrestart depends on:
ii  dpkg   1.18.7
ii  gettext-base   0.19.7-2
ii  libintl-perl   1.24-1
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.21-1
ii  libproc-processtable-perl  0.53-1+b1
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.33-1+b1
ii  perl   5.22.2-1
ii  xz-utils   5.1.1alpha+20120614-2.1

needrestart recommends no packages.

Versions of packages needrestart suggests:
ii  libnotify-bin0.7.6-2
ii  needrestart-session  0.3-2

-- no debconf information

Bug#747824: Activity ping for atom packaging

[Alexandre Viau]

Hello Jonathan,

> I'd like to make sure that atom is in the debian repository before
> the freeze.

Do you still plan to work on this? If not, please release the ownership 
of the bug.


Have you done anything yet? Can we help you to move forward? I would 
gladly sponsor uploads for atom dependencies.


Cheers,

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

Bug#826032: ally: 'org.gnome.desktop.a11y' does not contain a key named 'always-show-text-caret'

[Mattia Rizzolo]

control: close -1

On Wed, Jun 01, 2016 at 07:56:20PM +0200, robino wrote:
> Package: ally

I can't any package with this name, nor I could figure out what you
inteded with this.
Thus, I'm closing the bug report.

> Version: gnome desktop

And this is not a valid version for a package.

> Severity: normal
> 
> Some applications such as gedit and gconf-editor give this error message and
> don't start. This only happens in Wayland not Xorg.
> 
> (dconf-editor:14990): GLib-GIO-ERROR **: Settings schema
> 'org.gnome.desktop.a11y' does not contain a key named 'always-show-text-caret'
> Trace/breakpoint trap
> 
> (gedit:15797): GLib-GIO-ERROR **: Settings schema 'org.gnome.desktop.a11y' 
> does
> not contain a key named 'always-show-text-caret'
> Trace/breakpoint trap
> 
> This also happens in clean Gnome sessions (new users).
> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.5.0-2-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)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#280583: tsrsock vs. cyclades-ser-cli

[Jan-Benedict Glaw]

Hi!

This bug is trivial to fix, quite annoying and is two years old by
now. How about actually fixing it?

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: God put me on earth to accomplish a certain number of
the second  :things. Right now I am so far behind I will never die.


signature.asc
Description: Digital signature

Bug#719624: Upgrading xrdp

[Mike Gabriel]

Hi

On Wed Jun 1 20:23:15 2016 GMT+0200, Andreas Tille wrote:
> On Wed, Jun 01, 2016 at 08:16:20PM +0200, Dominik George wrote:
> > We tried to avoid updateing to a new upstream commit as the one in use was 
> > well-tested, but looking through the changes, there has been a big diff, 
> > but 
> > almost all of it seems to be fixing warnings and code formatting.
> > 
> > So right now, we'd prefer to just move to the most recent upstream commit 
> > (after testing, of course).
> 
> Sounds pretty sensible - please go for it.
> 
> Kind regards
> 
> Andreas.

/me nods from here, too.

-- 
Sent from my Jolla

Bug#825799: [Pkg-gmagick-im-team] Bug#825799: imagemagick: CVE-2016-5118

[Emilio Pozuelo Monfort]

On 01/06/16 12:58, Luciano Bello wrote:
> On Wednesday 01 June 2016 01.26.17 Emilio Pozuelo Monfort wrote:
>> I haven't had the time to look at jessie but the change should be similar.
> 
> I just released DSA 3591-1 to fix jessie.
> 
>> @maintainers: Would you like to upload this fix yourself or want me to do 
> it?
>> Just for wheezy/jessie or also for unstable?
> 
> Please, fill free to upload to wheezy and sid. Every hand is welcome :)

:)

> With respect to your suggested patches, I think the way to go with wheezy is 
> with a minimal patch (check out my upload in jessie). I think in sid is okey 
> to be more synchronized with upstream.

OK. My first patch was kinda similar to yours, adding an "&& 0" after the #ifdef
check so it would always evaluate to 0. I have changed it and taken yours to be
aligned here.

I have uploaded it to wheezy and to unstable (with the upstream patch for sid).

Cheers,
Emilio

Bug#826043: apt: gpg validation fails on hurd

[Adam Borowski]

Package: apt
Version: 1.2.12
Severity: important

Despite all the relevant keys being installed (debian-archive-keyring,
debian-ports-archive-keyring; "apt-key list" says they're there), I get:

W: GPG error: http://ftp.ports.debian.org/debian-ports unreleased InRelease:
The following signatures couldn't be verified because the public key is not
available: NO_PUBKEY B4C86482705A2CE1
W: The repository 'http://ftp.debian-ports.org/debian unreleased InRelease'
is not signed.
W: GPG error: http://ftp.pl.debian.org/debian sid InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 8B48AD6246925553  NO_PUBKEY 7638D0442B90D010
W: The repository 'http://ftp.pl.debian.org/debian sid InRelease' is not
signed.

Fetching these repositories on a Linux box (via "deb [arch=hurd-i386] ...")
succeeds.

Same failure happens no matter which mirror I choose.

This is a ~1.5 months old installation in virtualbox; trying today's
(2016-06-01) d-i image fails with "choose-mirror[2674] WARNING **: mirror
does not support the specified release (unstable)".  Again, switching
mirrors doesn't help.


This _may_ be an archive misconfiguration that got replicated to mirrors,
however, because fetching with "deb [arch=hurd-i386]" succeeds elsewhere,
this looks like an arch-specific problem with apt or an dependency to me.



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "hurd-i386";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-0\.7$";
APT::NeverAutoRemove:: "^linux-image-1\.6-486$";
APT::NeverAutoRemove:: "^linux-headers-0\.7$";
APT::NeverAutoRemove:: "^linux-headers-1\.6-486$";
APT::NeverAutoRemove:: "^linux-image-extra-0\.7$";
APT::NeverAutoRemove:: "^linux-image-extra-1\.6-486$";
APT::NeverAutoRemove:: "^linux-signed-image-0\.7$";
APT::NeverAutoRemove:: "^linux-signed-image-1\.6-486$";
APT::NeverAutoRemove:: "^kfreebsd-image-0\.7$";
APT::NeverAutoRemove:: "^kfreebsd-image-1\.6-486$";
APT::NeverAutoRemove:: "^kfreebsd-headers-0\.7$";
APT::NeverAutoRemove:: "^kfreebsd-headers-1\.6-486$";
APT::NeverAutoRemove:: "^gnumach-image-0\.7$";
APT::NeverAutoRemove:: "^gnumach-image-1\.6-486$";
APT::NeverAutoRemove:: "^.*-modules-0\.7$";
APT::NeverAutoRemove:: "^.*-modules-1\.6-486$";
APT::NeverAutoRemove:: "^.*-kernel-0\.7$";
APT::NeverAutoRemove:: "^.*-kernel-1\.6-486$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-0\.7$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-1\.6-486$";
APT::NeverAutoRemove:: "^linux-tools-0\.7$";
APT::NeverAutoRemove:: "^linux-tools-1\.6-486$";
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::Architectures "";
APT::Architectures:: "hurd-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";

Bug#826000: ifupdown: if-pre-up.d and if-up.d scripts are run twice at boot

[Guus Sliepen]

On Wed, Jun 01, 2016 at 09:06:20PM +0200, Vincent Lefevre wrote:

> On 2016-06-01 20:10:10 +0200, Guus Sliepen wrote:
> > It is normal that the if-*.d scripts are run multiple times. They are
> > run once for every iface stanza in /etc/network/interfaces (so if you
> > have both an inet and inet6 stanza for the same interface, the scripts
> > get run twice). But also, an "ifup --all" will cause an extra pass of
> > all the scripts, with IFACE set to "--all". Note that this is documented
> > in the interfaces manpage.
> 
> This means that various ifup scripts are probably buggy.

What makes you think that? According to what you said earlier, it was
hanging in z_home_net, which is not in any official Debian package, so I
assume this script was written by you? I haven't heard any reports of
other scripts breaking, and ifupdown has been calling the scripts with
IFACE="--all" since early 2012.

> Also, why doesn't ifup write a log message about --all?

So far there was no reason for it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#825548: quotactl(2) man page is incorrect

[Michael Kerrisk (man-pages)]

tags 825548 fixed-upstream
thanks

Hello Jacob

Upstream maintainer here. Thanks for the excellently documented report.

This error appears to have been injected into glibc when copying
some headers from BSD.

I've applied the patch below.

Cheers,

Michael

diff --git a/man2/quotactl.2 b/man2/quotactl.2
index 2cab4c0..8526a14 100644
--- a/man2/quotactl.2
+++ b/man2/quotactl.2
@@ -150,8 +150,8 @@ struct dqblk {  /* Definition since Linux 2.4.22 */
   quota blocks alloc */
 uint64_t dqb_bsoftlimit;   /* preferred limit on
   disk quota blocks */
-uint64_t dqb_curspace; /* current quota block
-  count */
+uint64_t dqb_curspace; /* current occupied space
+  (in bytes) */
 uint64_t dqb_ihardlimit;   /* maximum number of
   allocated inodes */
 uint64_t dqb_isoftlimit;   /* preferred inode limit */

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Bug#825861: freecad: After update to 0.16 design contents are "invisible", ViewProvider2DObjectPython on console

[Anton Gladky]

Hi Sascha,

thanks for bugreport.

2016-05-30 23:24 GMT+02:00 Sascha Silbe <
sascha-debian-bugs-freecad-2016-05...@silbe.org>:

> Creating, saving and loading a new file containing just a single wire
> seems to work fine, so it's only old and/or more complex documents
> that are broken. Still that's a major impact (it makes FreeCAD pretty
> much unusable for me right now), hence severity "important".


It can also happen that old/complex files, saved in a old freecad version
not fully supported by newly freecad version. Try to save them in another
format, if it is possible, and open again in a new version. Maybe upstream
people can help more on this problem.

You can get all versions of freecad on snapshots.debian.org if you need
to downgrade it.

Cheers

Anton

Bug#826040: [pppconfig] I do obtain the same error messages.

[Detlef Lechner]

Package: pppconfig
Version: 2.3.22

--- Please enter the report below this line. ---
I obtain the same error messages.

--- System information. ---
Architecture: amd64
Kernel: Linux 4.5.3-towo.1-siduction-amd64

Debian Release: stretch/sid
500 unstable httpredir.debian.org
500 unstable ftp.spline.de

--- Package information. ---
Depends (Version) | Installed
==-+-===
init-system-helpers (>= 1.18~) | 1.34
ppp (>= 2.3.7) | 2.4.7-1+2
whiptail | 0.52.18-3
OR dialog | 1.3-20160424-1


Package's Recommends field is empty.

Suggests (Version) | Installed
=-+-===
resolvconf | 1.79

Bug#824676: INSTALL_PATH was the issue

[Rob McAninch]

Apparently this was the issue. 

In the cleandb.sh script I commented out the line trying to guess the 
INSTALL_PATH and set it to /var/lib/roundcube/


-- 
Rob McAninch

Bug#821639: src:zeroc-ice: PHP 7.0 Transition

[Chris Knadle]

Jose Gutierrez de la Concha:
> Hi Ondřej,
> 
> I have been looking over the patches included in ice3.5 package, I think
> most of the patches are not longer required with 3.6, see comments below

[...]
> add-dpkg-buildflags
> 
> is this really required? we build packages with dh and the flags are
> being set without need to patch the 3.6 build system.

This patch is for adding Hardening flags, and was required because
hardening-wrapper didn't work with GCC 5 and zeroc-ice depended on it,
causing a bug whereby zeroc-ice was removed from Testing.

More info on Hardening here:

   https://wiki.debian.org/Hardening

Using 'dh' in debian/rules does not automatically harden in many cases
because it's common for Makefiles to hard-set build flags past what dh sets;
for instance this line that the patch changes from zeroc-ice 3.5.1:

   CPPFLAGS =

literally removes any CPPFLAGS that 'dh' would have set.

The best way I know of to test the hardening flags is to use 'blhc' on the
log of the build (in the 'blhc' package) -- the best result is no warning
output.  Try running blhc on your zeroc-ice 3.6 build logs.

> hurd-fixes
> 
> We haven't tested hurd at this point

I looked through the list of archived bugs for zeroc-ice and couldn't find
what this patch is related to.  (Too  bad this patch didn't have DEP3
headers.)  Hurd isn't an official release architecture for Debian, so "it's
good if it can be made to work where feasible".

[...]
> Let me know your thoughts on this

One other thing I should mention for clarity is that Debian *Sid* is the
target distribution -- because all uploads to go Sid.  *If* no serious bugs
get reported then the package automatically transitions to Testing
(currently named "Stretch") in about 5 days (assuming "urgency=medium" is
used in the changelog entry, which is the default).  So right now Stretch
generally follows Sid with a 5-day delay, but that will drastically change
when the freeze comes in November.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us