Bug#813451: Update with 4.4

[Philipp Kolmann]

Hi,

I tried to boot with 4.4 again. My Lilo.conf still fails to boot the box:

large-memory
lba32

boot=/dev/md0
raid-extra-boot=mbr-only
root=/dev/md0

install=menu
prompt
timeout=50

map=/boot/map

image=/boot/vmlinuz
label="Linux"
initrd=/boot/initrd.img
vga=791
read-only

image=/boot/vmlinuz.old
label="Linux.old"
initrd=/boot/initrd.img.old
vga=791
read-only
optional

image=/boot/memtest86+.bin
label="Memtest"



If I specify 'Linux root=/dev/md0' at the lilo promt, the system boots 
and works now with Linux wspk 4.4.0-1-amd64 #1 SMP Debian 4.4.2-3 
(2016-02-21) x86_64 GNU/Linux.


Somehow the system doesn't find the root partition.

thanks
Philipp

Bug#788102: not fixed

[Mathieu Malaterre]

Control: reopen -1

Previous patch disabled the functionality completely. We should use
Steven's patch instead. Re-opening issue (Thanks Steven!)

Bug#815631: sphinx: Use alternatives to provide scripts under /usr/bin

[Dmitry Shachnev]

Hi Kevin,

On Tue, Feb 23, 2016 at 02:34:11PM +1100, Kevin Murray wrote:
> I have recently needed to use a python3-only sphinx build process on a
> system with both python-sphinx & python3-sphinx co-installed. IMHO 
> co-installation
> could be a little cleaner and easier if sphinx:
> 
> - Used update-alternatives to provide /usr/bin/sphinx-* in a
>   configurable way. (e.g similar to how docutils handles this problem). This
>   could use the current script installation path under
>   /usr/share/sphinx/scripts/python*/

Let me quote Jakub Wilk, who wrote the current implementation:

  The alternatives mechanism is only suitable if both commands are compatible,
  i.e. their behavior doesn't vary with Python version. This is the case for
  rst2html and friends, but no so much for sphinx-build. The problem is that
  sphinx-build can import 3rd-party Python code, which is not necessarily
  compatible with both Python 2 and 3.

> - Or, installed binaries under /usr/bin with the suffix '3', i.e. install
>   /usr/bin/sphinx-build3. (modelled after pip/pip3 & nosetests/nosetests3 and
>   other similar examples)

The name of sphinx-build command is hardcoded in too many places (i.e. the
Makefiles generated by Sphinx use it). Also, I don't much like the foo/foo3
naming because there is a better way: pythonX[.Y] -m sphinx allows one to
call sphinx-build with *any* Python version (not necessarily the default one).

> - Or, a combination of both these, where python-sphinx and
>   python3-sphinx install /usr/bin/sphinx-*{2,3} respectively, and
>   update-alternatives is used to provide /usr/bin/sphinx-* without
>   prefix.

See above.

> P.S., I know one can always do /usr/share/sphinx/scripts/python3/sphinx-build
> as a workaround.

What is exactly your problem? Does Python 2 sphinx not work with your code?
Can you use python3 -m sphinx there? Or maybe use setuptools' build_sphinx
command?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#814982: [xwayland] Reproducible segmentation fault when pluggin new

[Yasushi SHOJI]

Hi,

I'm seeing the same problem for last few weeks.  The backtrace is
basically the same.

No new info from me but just to let you know that it segfaults here
too.
-- 
  yashi

Bug#815555: initramfs-tools: raid1 boot with lilo fails on 0.123 with cant find root in fstab

[Anders Nyvang]

On 22 February 2016 at 23:09, Ben Hutchings  wrote:

> Control: tag -1 moreinfo
>
> On Mon, 2016-02-22 at 12:58 +0100, Anders Nyvang wrote:
> > Package: initramfs-tools
> > Version: 0.123
> > Severity: critical
> > Justification: breaks the whole system
> >
> > Dear Maintainer,
> >
> > After updating from 0.120 to 0.123 my system cannot boot.
> >
> > System is software raid1 and booting with lilo.
> >
> > Post up to the initramfs prompt:
> > BIOS data check successful
> > mdadm: /dev/md0 has been started with 2 drives.
> > modprobe: module unknown not found in modules.dep
> > mount: can't find /root in /etc/fstab
> >
> > ... and the errors goes on, but primary relates to the fact that the
> root filesystem is missing.
> [...]
>

All returns Ext4.


> What filesystem type is the root mounted with, when you use
> initramfs-tools 0.120?  (Check in /proc/mounts.)
>

# cat /proc/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=254169,mode=755 0 0
devpts /dev/pts devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=205288k,mode=755 0 0
/dev/root / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
pstore /sys/fs/pstore pstore rw,relatime 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=799340k 0 0


> What does '/usr/lib/klibc/bin/fstype /dev/md0' show?
>

# /usr/lib/klibc/bin/fstype /dev/md0
FSTYPE=ext4
FSSIZE=33361625088


> What does 'blkid /dev/md0' show?
>

# blkid /dev/md0
/dev/md0: UUID="5a290e58-0d5e-46aa-8e07-019526f4499f" TYPE="ext4"


> Ben.
>
> --
> Ben Hutchings
> The generation of random numbers is too important to be left to chance.
> - Robert
> Coveyou


/Anders

Bug#806595: aptitude: now it crashes

[Jason Woofenden]

OK, I created a new bug for the segfault:

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

With a backtrace and everything :)

-- 
Jason

Bug#815635: aptitude: crashes on x86 on shift-C (changelog)

[Jason Woofenden]

Package: aptitude
Version: 0.7.6-1
Severity: normal

Dear Maintainer,

Hi, since 0.7.6-1 I consistently get a segfault when I press
Shift-C to view a changelog.

A couple people reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806595 that they
don't get this crash on amd64, and one of them said that they do get
the crash on x86 (like me).

Here's a backtrace:

#0  0x8011ee6e in std::__cxx11::basic_string::_Alloc_hider::_Alloc_hider (__a=...,
__dat=, this=) at 
/usr/include/c++/5/bits/basic_string.h:109
#1  std::__cxx11::basic_string::basic_string (__str=..., this=0xbfffe734)
at /usr/include/c++/5/bits/basic_string.h:399
#2  aptitude::apt::changelog::get_filename[abi:cxx11]() const (this=) at ../../src/generic/apt/changelog_parse.h:229
#3  do_view_changelog 
(filename="/tmp/aptitude-root.31049:inX5Pb/aptitude-download-T0DKG^77xIW3.iCvfIbO3D5CNdigfit5_1811-fd54-2439-6e19",
pkgname="cgpt", curverstr="0~20121212-3") at ../../src/view_changelog.cc:303
#4  0x801212a4 in changelog_callbacks::success (this=0x80d29214,

filename="/tmp/aptitude-root.31049:inX5Pb/aptitude-download-T0DKG^77xIW3.iCvfIbO3D5CNdigfit5_1811-fd54-2439-6e19")
at ../../src/view_changelog.cc:364
#5  0x8020f068 in aptitude::apt::(anonymous 
namespace)::changelog_download::success (this=0x818c2014,

filename="/tmp/aptitude-root.31049:inX5Pb/aptitude-download-T0DKG^77xIW3.iCvfIbO3D5CNdigfit5_1811-fd54-2439-6e19")
at ../../../../src/generic/apt/pkg_changelog.cc:274
#6  0x801e4f36 in sigc::bound_mem_functor1 
const&>::operator() (_A_a1=..., this=0x80d41448) at 
/usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1856
#7  sigc::adaptor_functor const&> 
>::operator()&> (
_A_arg1=..., this=0x80d41444) at 
/usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:89
#8  sigc::bind_functor<-1, sigc::bound_mem_functor1 const&>, 
std::__cxx11::basic_string, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, 
sigc::nil>::operator() (this=0x80d41440) at 
/usr/include/sigc++-2.0/sigc++/adaptors/bind.h:1117
#9  sigc::internal::slot_call0 
const&>, std::__cxx11::basic_string, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, 
sigc::nil>, void>::call_it (rep=0x80d41428)
at /usr/include/sigc++-2.0/sigc++/functors/slot.h:108
#10 0x801e5de0 in sigc::slot0::operator() (this=0x80ce834c) at 
/usr/include/sigc++-2.0/sigc++/functors/slot.h:440
#11 keepalive (f=...) at 
../../../../src/generic/util/post_thunk.h:43
#12 0x801e4fb2 in sigc::pointer_functor2 const&, 
std::shared_ptr const&, void>::operator() 
(_A_a2=..., _A_a1=..., this=0x80ce8348)
at /usr/include/sigc++-2.0/sigc++/functors/ptr_fun.h:147
#13 sigc::adaptor_functor const&, 
std::shared_ptr const&, void> 
>::operator()&, 
std::shared_ptr&> (_A_arg2=..., _A_arg1=..., 
this=0x80ce8344)
at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:108
#14 sigc::bind_functor<-1, sigc::pointer_functor2 const&, 
std::shared_ptr const&, void>, sigc::slot, 
std::shared_ptr, sigc::nil, sigc::nil, sigc::nil, 
sigc::nil, sigc::nil>::operator() (
this=0x80ce8340) at /usr/include/sigc++-2.0/sigc++/adaptors/bind.h:1333
#15 sigc::internal::slot_call0 const&, 
std::shared_ptr const&, void>, sigc::slot, 
std::shared_ptr, sigc::nil, sigc::nil, sigc::nil, 
sigc::nil,
sigc::nil>, void>::call_it (rep=0x80ce8328) at 
/usr/include/sigc++-2.0/sigc++/functors/slot.h:108
#16 0x80118443 in sigc::slot0::operator() (this=0xbfffedc4) at 
/usr/include/sigc++-2.0/sigc++/functors/slot.h:440
#17 aptitude::safe_slot_event::dispatch (this=0xb1f47158) at 

Bug#805049: Let's Encrypt Deflate Bug

[Harlan Lieberman-Berg]

Tags: +moreinfo 
Hi Achim,

I've looked through the upstream bug tracker and tested myself, and this
no longer seems to be a problem.

If it is still broken for you with 0.4.0, please let us know.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Bug#815634: RFS: proxychains/3.1-7

[Daniel Echeverry]

Package: sponsorship-requests
Severity: normal

 Dear mentors,

  I am looking for a sponsor for my package "proxychains"

 * Package name: proxychains
   Version : 3.1-7
   Upstream Author : Net Creature, Proxy Labs
 * URL : http://proxychains.sourceforge.net
 * License : GPL-2.0
   Section : net

  It builds those binary packages:

 libproxychains-dev - proxy chains -- shared library (development)
 libproxychains3 - proxy chains -- shared library (runtime)
 proxychains - proxy chains - redirect connections through proxy servers

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

  http://mentors.debian.net/package/proxychains

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

dget -x 
http://mentors.debian.net/debian/pool/main/p/proxychains/proxychains_3.1-7.dsc

Changes since the last upload:

  Fix FTBS when built dpkg-buildpackage -a Closes: #806097
+ debian/rules
  + Add -arch variants of the dh_auto_*
  + Add hardening flags
  * Bump standard versions 3.9.7 (no changes)
  * Add libproxychains3.symbols file
  * debian/control
+ Remove autotools-dev in B-D
  * debian/copyright
+ Extend copyright holder years


Regards,
Daniel Echeverry

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
Linux user: #477840
Debian user
Software libre

Bug#422882: sign-in Alert

[Zimbra]

Dear Zimbra User,
 
This is to inform you that someone else was trying to log into your Zimbra 
account from a different location {IP:27.167.158.432 CHINA : 22/02/2016 by 
03:10 PM GTM}
 
If this is not you kindly click below to sign in to update and verify your 
account for you have only 12 hours to do this in order to keep your Zimbra 
account active.

Click Here to verify your Account.
 
 This Email is Subject to mandatory follow, Failure to comply would lead to 
Permanent closure of Account.
Regards,
Technical support team

Bug#788102: The code doesn't compile on kfreebsd

[Steven Chamberlain]

Hi,

Mathieu Malaterre wrote:
> Steven Chamberlain  wrote:
> > Gianfranco Costamagna wrote:
> >> file.c:5:38: error: ‘mcontext_t’ has no member named ‘fpregs’
> >> uint32_t mxcsr = ucon.uc_mcontext.fpregs->mxcsr;
> >
> > FreeBSD doesn't seem to have fpregs in mcontext_t or sigcontext.
> > But I think mc_fpstate might be the same thing;  but that isn't
> > implemented as a struct...
> 
> Correct. Looks like other are handling it this way also
> https://github.com/fukamachi/clozure-cl/blob/master/level-1/x86-trap-support.lisp

For future reference, I came up with this alternate implementation of
restoreControlRegs() for kFreeBSD (untested, except it builds and passes
the testsuite):

#include 

inline void
restoreControlRegs (const ucontext_t & ucon, bool clearExceptions)
{
struct envxmm *ex = (struct envxmm *)(ucon.uc_mcontext.mc_fpstate);
setCw ((ex->en_cw & cwRestoreMask) | cwRestoreVal);
setMxcsr (ex->en_mxcsr, clearExceptions);
}

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#815633: ilmbase: symbols file update for kfreebsd

[Steven Chamberlain]

Package: ilmbase
Version: 2.2.0-9
Severity: important
Tags: patch

Hi!

Now that ilmbase is building again on kfreebsd, it needs a symbols file
update.  Please find a new one attached, and also a diff from the one in
2.2.0-9.

Thanks very much.

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- debian/libilmbase12.symbols.orig	2016-02-22 13:57:40.0 +
+++ debian/libilmbase12.symbols	2016-02-23 04:01:08.432737347 +
@@ -15,39 +15,42 @@
  _ZN7Iex_2_210EbadmsgExcD0Ev@Base 2.2.0
  _ZN7Iex_2_210EbadmsgExcD1Ev@Base 2.2.0
  _ZN7Iex_2_210EbadmsgExcD2Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EbadrqcExcD0Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EbadrqcExcD1Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EbadrqcExcD2Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EbadsltExcD0Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EbadsltExcD1Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EbadsltExcD2Ev@Base 2.2.0
+(arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EbadrqcExcD0Ev@Base 2.2.0
+(arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EbadrqcExcD1Ev@Base 2.2.0
+(arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EbadrqcExcD2Ev@Base 2.2.0
+(arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EbadsltExcD0Ev@Base 2.2.0
+(arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EbadsltExcD1Ev@Base 2.2.0
+(arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EbadsltExcD2Ev@Base 2.2.0
  _ZN7Iex_2_210EdeadlkExcD0Ev@Base 2.2.0
  _ZN7Iex_2_210EdeadlkExcD1Ev@Base 2.2.0
  _ZN7Iex_2_210EdeadlkExcD2Ev@Base 2.2.0
  _ZN7Iex_2_210EisconnExcD0Ev@Base 2.2.0
  _ZN7Iex_2_210EisconnExcD1Ev@Base 2.2.0
  _ZN7Iex_2_210EisconnExcD2Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibaccExcD0Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibaccExcD1Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibaccExcD2Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibbadExcD0Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibbadExcD1Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibbadExcD2Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibmaxExcD0Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibmaxExcD1Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibmaxExcD2Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibscnExcD0Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibscnExcD1Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210ElibscnExcD2Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EnavailExcD0Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EnavailExcD1Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EnavailExcD2Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibaccExcD0Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibaccExcD1Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibaccExcD2Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibbadExcD0Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibbadExcD1Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibbadExcD2Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibmaxExcD0Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibmaxExcD1Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibmaxExcD2Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibscnExcD0Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibscnExcD1Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210ElibscnExcD2Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EnavailExcD0Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EnavailExcD1Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EnavailExcD2Ev@Base 2.2.0
+ (arch=kfreebsd-any)_ZN7Iex_2_210EnoattrExcD0Ev@Base 2.2.0
+ (arch=kfreebsd-any)_ZN7Iex_2_210EnoattrExcD1Ev@Base 2.2.0
+ (arch=kfreebsd-any)_ZN7Iex_2_210EnoattrExcD2Ev@Base 2.2.0
  _ZN7Iex_2_210EnobufsExcD0Ev@Base 2.2.0
  _ZN7Iex_2_210EnobufsExcD1Ev@Base 2.2.0
  _ZN7Iex_2_210EnobufsExcD2Ev@Base 2.2.0
- _ZN7Iex_2_210EnodataExcD0Ev@Base 2.2.0
- _ZN7Iex_2_210EnodataExcD1Ev@Base 2.2.0
- _ZN7Iex_2_210EnodataExcD2Ev@Base 2.2.0
+ (arch=!kfreebsd-any)_ZN7Iex_2_210EnodataExcD0Ev@Base 2.2.0
+ (arch=!kfreebsd-any)_ZN7Iex_2_210EnodataExcD1Ev@Base 2.2.0
+ (arch=!kfreebsd-any)_ZN7Iex_2_210EnodataExcD2Ev@Base 2.2.0
  _ZN7Iex_2_210EnoexecExcD0Ev@Base 2.2.0
  _ZN7Iex_2_210EnoexecExcD1Ev@Base 2.2.0
  _ZN7Iex_2_210EnoexecExcD2Ev@Base 2.2.0
@@ -60,15 +63,15 @@
  _ZN7Iex_2_210EnotdirExcD0Ev@Base 2.2.0
  _ZN7Iex_2_210EnotdirExcD1Ev@Base 2.2.0
  _ZN7Iex_2_210EnotdirExcD2Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EnotnamExcD0Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EnotnamExcD1Ev@Base 2.2.0
- (arch=!hurd-i386)_ZN7Iex_2_210EnotnamExcD2Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EnotnamExcD0Ev@Base 2.2.0
+ (arch=!hurd-i386 !kfreebsd-any)_ZN7Iex_2_210EnotnamExcD1Ev@Base 2.2.0
+ 

Bug#789992: Been having this problem as well

[Alex Henry]

Been having this problem as well so I just wanted to let anyone else who
stumble upon this bug know that the 'qcomicbook' Debian package works fine
with unrar-free.

Bug#815632: gnubiff: Fails to read config at startup

[Omen Nemo]

Package: gnubiff
Version: 2.2.15-4
Severity: normal

Dear Maintainer,

With 2.2.16-1, gnubiff fails to load the config at startup, with the error:
** (gnubiff:5100): WARNING **: Configuration file () not found!
Settings are then all default.

With 2.2.15-4, all is fine.

Giving the path to the file "gnubiff -c /home/user1/.gnubiffrc" does not help.

With strace, I see (no option given):
- 1st try: open("\270\10[\te/user1/.gnubiffrc", O_RDONLY|O_LARGEFILE)
= -1 ENOENT (No such file or directory)
- 2nd try: open("\20\210\301\te/user1/.gnubiffrc",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
- 3rd try: open("08h\te/user1/.gnubiffrc", O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
which looks like a string buffer being overwritten.

Looking at the code, I followed to Options::value_string in
options.cc, but the code hasn't changed between 2.2.15-4 and 2.2.16-1
(no code has changed, actually)
I couldn't locate the dbg package to dig deeper with gdb.

Thanks!
Omen


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

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

Versions of packages gnubiff depends on:
ii  dpkg 1.18.4
ii  gconf-service3.2.6-3
ii  install-info 6.1.0.dfsg.1-2
ii  libatk1.0-0  2.16.0-2
ii  libc62.21-7
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libfam0  2.7.0-17.1+b1
ii  libgcc1  1:5.3.1-9
ii  libgconf-2-4 3.2.6-3
ii  libgdk-pixbuf2.0-0   2.31.5-1
ii  libglib2.0-0 2.46.2-3
ii  libgtk-3-0   3.16.6-1
pn  libpanel-applet-4-0  
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpopt0 1.16-10
ii  libssl1.0.0  1.0.2d-1
ii  libstdc++6   5.3.1-9
ii  libx11-6 2:1.6.3-1
ii  sox  14.4.1-5

Versions of packages gnubiff recommends:
pn  fam  

gnubiff suggests no packages.

-- no debconf information

Bug#815631: sphinx: Use alternatives to provide scripts under /usr/bin

[Kevin Murray]

Source: sphinx
Severity: normal

Dear Maintainer,

I have recently needed to use a python3-only sphinx build process on a
system with both python-sphinx & python3-sphinx co-installed. IMHO 
co-installation
could be a little cleaner and easier if sphinx:

- Used update-alternatives to provide /usr/bin/sphinx-* in a
  configurable way. (e.g similar to how docutils handles this problem). This
  could use the current script installation path under
  /usr/share/sphinx/scripts/python*/

- Or, installed binaries under /usr/bin with the suffix '3', i.e. install
  /usr/bin/sphinx-build3. (modelled after pip/pip3 & nosetests/nosetests3 and
  other similar examples)

- Or, a combination of both these, where python-sphinx and
  python3-sphinx install /usr/bin/sphinx-*{2,3} respectively, and
  update-alternatives is used to provide /usr/bin/sphinx-* without
  prefix.

Is there any reason that one of these approaches have not been taken? I'm
relatively new to Debian packaging so there may be subtlety here I'm
missing.

I'm happy to have a go at implementing a solution to this myself, given
guidance as to the best option to implement (if any).

Cheers,
Kevin

P.S., I know one can always do /usr/share/sphinx/scripts/python3/sphinx-build
as a workaround.

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

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

---
Kevin Murray
0xA4B4EE6A

Bug#814030: Intent to bring php-tcpdf in the Debian PHP PEAR (and Composer) Maintainers team (Was: Bug#814030: Security flaw fixed in version 6.2.0)

[David Prévot]

Hi,

On Sun, Feb 07, 2016 at 02:28:04PM -0400, David Prévot wrote:
> Package: php-tcpdf
> Version: 6.0.093+dfsg-1
> Severity: serious
> Tags: security upstream
> 
> According to their changelog [1], upstream fixed a security issue over a
> year ago: […]

In order to bring php-tcpdf back in line with upstream, and to follow
more closely the PHP class packaging, I’d like to take the
opportunity of team maintaining it under the Debian PHP PEAR (and
Composer) Maintainers umbrella.

Unless someone objects, I intend to move forward as soon as I have some
time to spare on it.

Regards

David


signature.asc
Description: PGP signature

Bug#815630: 2.4.67-1 causes black screen after login on plasma desktop

[Sten Heinze]

Package: libdrm-intel1
Version: 2.4.67-1
Severity: important

Dear Maintainer,

Updating libdrm-intel1 from 2.4.66-2 to 2.4.67-1 causes a black screen after 
logging into the 
plasma desktop. Only the mouse is still visible and the blue glow around the 
start menu 
whenever the mouse moves over it. The function of the login screen (SDDM) is 
unchanged.

Downgrading libdrm-intel1 to 2.4.66-2 fixes this problem and results in a 
normally working
desktop.

Please let me know if I can provide additional information or can test 
different hypotheses.


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

Kernel: Linux 4.3.0-1-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 libdrm-intel1 depends on:
ii  libc6  2.21-8
ii  libdrm22.4.67-1
ii  libpciaccess0  0.13.4-1

libdrm-intel1 recommends no packages.

libdrm-intel1 suggests no packages.

-- no debconf information

Bug#773554: python-scapy: new upstream version available

[Douglas Calvert]

Package: python-scapy
Version: 2.2.0-1
Followup-For: Bug #773554

Hello,

Any news on getting the most recent version of scapy updated? The version in 
unstable is 5 years old now. 

https://github.com/secdev/scapy/releases


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

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

Versions of packages python-scapy depends on:
ii  python 2.7.11-1
ii  python2.7  2.7.11-3

python-scapy recommends no packages.

Versions of packages python-scapy suggests:
ii  ebtables2.0.10.4-3.4
ii  graphviz2.38.0-12+b1
pn  gv  
ii  hexer   0.2.3-1
ii  imagemagick 8:6.8.9.9-7+b1
ii  librsvg2-bin2.40.13-3
ii  python-crypto   2.6.1-6
ii  python-gnuplot  1.8-6
ii  python-pcapy0.10.8-1+b1
ii  python-pyx  0.12.1-4
ii  python-visual   1:5.12-1.6+b4
ii  sox 14.4.1-5
ii  tcpdump 4.7.4-1+b1
ii  tcpreplay   3.4.4-2
ii  wireshark   2.0.1+g59ea380-3+b1
pn  xpdf

-- no debconf information

Bug#815629: RFS: singular/4.0.3+ds-1 [NEW VERSION] -- Computer Algebra System for Polynomial Computations

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors:

I am looking for a sponsor to bring to Debian the last upstream version of 
Singular,
a powerful Computer Algebra System; Singular is a core part of Sage.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/singular.git

-- 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#815515: solved with preseed

[Andreas Beckmann]

On 2016-02-22 02:24, Bob wrote:
> Found out nvidia-legacy-check can be disabled by preseeding it.

Just to clarify: the test itself is working correctly, it just prevents
a non-interactive installation (since the default is "abort").
And exactly for this scenario I added the preseedability.

I'll mention in the description of the package that the debconf question
is "preseedable".


And in your original bug report you wrote:

On 2016-02-22 01:08, Bob wrote:
> error when no compatible card is found in the active machine.
 ^^

Here you probably mean "an incompatible card", since the packages should
install without any questions if no NVIDIA graphics hardware is
available at all.


Andreas

Bug#815628: dicom3tools: dcintro man page missing

[Karl O. Pinc]

Package: dicom3tools
Version: 1.00~20140902075059-1
Severity: normal

Hi,

All the man pages mention a dcintro man page, which is supposed
to explain all the common options.  But there is no dcintro man
page packaged.

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

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

Versions of packages dicom3tools depends on:
ii  libc6   2.19-18+deb8u3
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

Versions of packages dicom3tools recommends:
ii  netpbm  2:10.0-15.2

Versions of packages dicom3tools suggests:
pn  pvrg-jpeg  

-- no debconf information

Bug#815627: QCOM: addition options required to boot

[Martin Michlmayr]

Package: linux
Version: 4.4.2-3
Severity: important

I requested QCOM be enabled in #812386.  I just found out that I need
at least the following options to boot the kernel on my hardware (a
DragonBoard 410c):

CONFIG_COMMON_CLK_QCOM=y
CONFIG_MSM_GCC_8916=y

CONFIG_PINCTRL_MSM8916=y

(I suspect it makes sense to enable other CONFIG_MSM_GCC_* and
CONFIG_PINCTRL_MSM* options, too.)

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#815125: Boot failure with Debian linux 4.4.2 package

[Norbert Preining]

unmerge 815125
found 815125 4.4.2-3
thanks

Hi Ben,

I have now tried the kernel you uploaded and it shows the same
problems, so it seems related to something else.

When I add earlyprintk=efi,keep it boots extremely slow, see this
little (6sec) video
https://www.dropbox.com/s/9axz9s7afi0oqbv/booting-macpro.mp4?dl=0

It stops at the same place as before, so please see the previously
attached screenshots.

Thanks

Norbert


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

Bug#798145: RFP: brial -- polynomials over Boolean Rings

[Tobias Hansen]

Hi,

I started packaging brial in the packaging git repo of polybori at [1].
Some parts of polybori are still in brials git repo, but not in the
release tarballs, namely the gui, the ipython interface and the
documentation. Do you know if these parts will be supported again in the
future?

Best,
Tobias

[1] http://anonscm.debian.org/cgit/debian-science/packages/polybori.git

Bug#812741: neovim: Please don't build-depend on luajit on unsupported architectures

[James McCoy]

On Mon, Feb 22, 2016 at 02:08:23PM +0100, John Paul Adrian Glaubitz wrote:
> On 02/22/2016 01:05 PM, James McCoy wrote:
> > It's currently possible to build without LuaJIT, as long as you don't
> > want to run tests. However there are plans to embed LuaJIT into neovim.
> 
> The moment they start embedding LuaJIT into neovim, the package needs
> to be patched or it will be removed out of Debian.

That's a bit of an overreaction.  What I meant was what's typically
meant when talking of embedding a language[0][1][2] (especially with
Lua), using the language's functionality from the application.

[0]: 
https://docs.python.org/3/extending/index.html#embedding-the-cpython-runtime-in-a-larger-application
[1]: https://metacpan.org/pod/perlembed
[2]: http://www.lua.org/manual/5.1/manual.html#3

> > Given that, I don't see it worthwhile to try and workaround the issue.
> > LuaJIT needs to be supported.
> 
> I still don't see what warrants the requirement of LuaJIT in a text
> editor which could not replaced by the regular Lua interpretor.

As I mentioned earlier, LuaC doesn't provide FFI which is something they
apparently want to use.  Also, one of the major purposes they're looking
at for using Lua(JIT) is translating VimL to Lua and then executing
that.  The thought is that using Lua itself instead of LuaJIT would make
that too slow.  Some more information on what has been under discussion
can be seen in .

Regardless, I don't see why you're having such a strong reaction to
this.  It's their design choice and just because it limits what
architectures they'll be able to run on it isn't reason enough to
consider this a bug.  There are plenty of applications in Debian which
don't run on all the supported architectures/kernels.

Bram took extreme efforts to keep compatibility with arcane and mostly
unused computers/OSes and that's something the Neovim folks have decided
not to continue, for better or worse.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#810947: kwin-x11: iceweasel locks up when multiple windows restored

[Arthur Marsh]

Package: kwin-x11
Followup-For: Bug #810947

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)?

After a few more updates, I am not seeing lock-ups any more.

   * 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: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-rc5+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kwin-x11 depends on:
ii  kwin-common  4:5.5.4-2
ii  libc62.21-9
ii  libkf5i18n5  5.16.0-1
ii  libkf5windowsystem5  5.16.0-1
ii  libqt5core5a 5.5.1+dfsg-14
ii  libqt5gui5   5.5.1+dfsg-14
ii  libqt5widgets5   5.5.1+dfsg-14
ii  libqt5x11extras5 5.5.1-3
ii  libstdc++6   6-20160205-1
ii  libxcb1  1.11.1-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- debconf-show failed

Bug#813946: aisleriot: Yukon variant: statistic is wrong

[Christian Knoke]

This bug might be considered as invalid.

Since I do not play games to the very end, but stop, when all cards lay open
and the win is for sure, avoiding the burden of tiling up all cards, these
games are not counted by statistics, when I close or start a new game then.

Nevertheless you might want to change that ...

Christian

-- 
Christian Knoke* * *http://cknoke.de
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.

Bug#815588: fglrx-driver: please track libva driver ABI using dh_libva

[Andreas Beckmann]

Control: tag -1 pending

On 2016-02-22 19:38, Sebastian Ramacher wrote:
> All other VA driver packages currently track the supported libva driver ABI by
> depending on libva-driver-abi-X.Y. dh_libva can be used to generate the
> dependencies automatically from the driver. Please consider tracking the 
> driver
> ABI version the same way.

Thanks, I didn't know about that.

> (While testing the patch I noticed that the driver only supports ABI version
> 0.32 and 0.33. We're up to 0.38 now, so it'd be nice to have entry points for
> newer versions as well.)

The blob also doesn't support the xserver we currently have in sid ... :-(


Andreas

Bug#813881: [PATCH 1/1 v3] ARM: dts: imx6dlq-wandboard-revb1.dts: use unique model id

[Ben Hutchings]

On Tue, 2016-02-23 at 08:11 +0900, Roger Shimizu wrote:
> Dear Ben,
> 
> On Sun, Feb 14, 2016 at 9:59 PM, Roger Shimizu  wrote:
> > Dear Kernel Maintainer,
> > 
> > On Sun, Feb 14, 2016 at 6:01 PM, Heinrich Schuchardt  wrote:
> > > Shawn Guo the Linux kernel maintainer of ARM/Freescale IMX / MXC ARM
> > > architecture has accepted my appended patch 0001-ARM... to change the
> > > model id of the Wandboard Quad Rev B1 and the Wandboard Dual Rev B1.
> > > 
> > > See
> > > https://lkml.org/lkml/2016/2/14/34
> > > https://lkml.org/lkml/2016/2/7/270
> > > 
> > > I suggest to add the patch to
> > > linux-source-4.3 (debian/patches/bugfix/arm)
> > > and to update flash-kernel (patch 0001-db... appended).
> > 
> > I also have a few device-tree "fixes", as well as "for-next" applied
> > by upstream sub-system maintainer.
> > For "fixes", some of those're already got merged into linus's 4.5-rc
> > tree, and will, AFAIK, be backported to each related/affected stable
> > kernel, and finally reach Debian's stable kernel; for "for-next", it's
> > waiting for the next merge window (to say, 4.6).
> > 
> > I also want to know what's debian's kernel policy [0] on backporting
> > those device-tree file.
> > 
> > Please help to clarify. Thank you!
> > 
> > [0]: https://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
> 
> Could you help to comment on this, please?
> 
> If you think backporting those device-tree to "master"/"sid" is fine,
> I can handle both the patch mention in this thread and a few
> Linkstation device-tree patch I submitted.

Yes, this is all fine for sid.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

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

Bug#539201: Patch

[Raphaël Halimi]

Control: tags -1 patch

Hi,

Here's a patch to implement RPCNFSDOPTS.

Regards,

-- 
Raphaël Halimi
diff --git a/debian/nfs-kernel-server.default b/debian/nfs-kernel-server.default
index 7137dae..682c45e 100644
--- a/debian/nfs-kernel-server.default
+++ b/debian/nfs-kernel-server.default
@@ -1,3 +1,7 @@
+# Options for rpc.nfsd
+# To disable NFSv4 on the server, specify '--no-nfs-version 4' here
+RPCNFSDOPTS=""
+
 # Number of servers to start up
 RPCNFSDCOUNT=8
 
diff --git a/debian/nfs-kernel-server.init b/debian/nfs-kernel-server.init
index e0c51d6..dba5c66 100644
--- a/debian/nfs-kernel-server.init
+++ b/debian/nfs-kernel-server.init
@@ -25,6 +25,7 @@ PREFIX=/usr
 
 # Read config
 DEFAULTFILE=/etc/default/nfs-kernel-server
+RPCNFSDOPTS=
 RPCNFSDCOUNT=8
 RPCNFSDPRIORITY=0
 RPCMOUNTDOPTS=
@@ -100,7 +101,7 @@ case "$1" in
 
 		start-stop-daemon --start --oknodo --quiet \
 		--nicelevel $RPCNFSDPRIORITY \
-		--exec $PREFIX/sbin/rpc.nfsd -- $RPCNFSDCOUNT
+		--exec $PREFIX/sbin/rpc.nfsd -- $RPCNFSDOPTS $RPCNFSDCOUNT
 		RET=$?
 		if [ $RET != 0 ]; then
 			log_end_msg $RET


signature.asc
Description: OpenPGP digital signature

Bug#657098: sign-in Alert

[Zimbra]

Dear Zimbra User,
 
This is to inform you that someone else was trying to log into your Zimbra 
account from a different location {IP:27.167.158.432 CHINA : 22/02/2016 by 
03:10 PM GTM}
 
If this is not you kindly click below to sign in to update and verify your 
account for you have only 12 hours to do this in order to keep your Zimbra 
account active.

Click Here to verify your Account.
 
 This Email is Subject to mandatory follow, Failure to comply would lead to 
Permanent closure of Account.
Regards,
Technical support team

Bug#814664: [Pkg-roundcube-maintainers] Bug#814664: Incorrect hardcoded php-auth and other dependencies

[David Prévot]

Hi Sandro,

> but with that I get:
> phpcomposer:Debian-require=php5-common, php5-common (>= 5.3.7),
> php-roundcube-plugin-installer (>= 0.1.6),
php-roundcube-plugin-installer (<< 0.2~~),
[…]
> do i miss an option for  dh_phpcomposer to get rid of these << XX~~ parts?
> Or are they needed?

They are actually a fair translation of the composer.json file content
(IOW, nothing wrong with these << XX~~ parts). You can have a look at the
Composer doc for the reference documentation, and follow up to
pkg-php-pear@l.d.o if you disagree with the current translation
(everything can be improved ;).

Regards

David

Bug#815626: aisleriot: Yukon variant: Loss detection blocks user from PM analysis

[Christian Knoke]

Package: aisleriot
Version: 1:3.4.1-1
Severity: normal

On detection of game loss, the Yukon solver presents a modal window with
following choices:

move back/close game/restart game/new game

Especially in regard of #813945 , I consider this as a bug.

Besides there might be the slightest chance the detection can be in error,
the user cannot do an analysis of the situation, because the UI blocks the
user effectively from playing beyond that move.

Christian


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

Kernel: Linux 3.2.0-4-686-pae (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

Versions of packages aisleriot depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.12.1-3
ii  gconf-service3.2.5-1+build1
ii  gconf2   3.2.5-1+build1
ii  guile-2.0-libs   2.0.5+1-3
ii  libatk1.0-0  2.4.0-2
ii  libc62.13-38+deb7u10
ii  libcairo21.12.2-3
ii  libcanberra-gtk3-0   0.28-6
ii  libcanberra0 0.28-6
ii  libgconf-2-4 3.2.5-1+build1
ii  libgdk-pixbuf2.0-0   2.26.1-1+deb7u3
ii  libglib2.0-0 2.33.12+really2.32.4-5
ii  libgtk-3-0   3.4.2-7
ii  librsvg2-2   2.36.1-2

aisleriot recommends no packages.

Versions of packages aisleriot suggests:
pn  gnome-cards-data  

-- no debconf information

Bug#815625: redmine: fails to install: /usr/lib/ruby/vendor_ruby/molinillo/dependency_graph.rb:109:in `add_vertex': wrong number of arguments (3 for 2) (ArgumentError)

[Andreas Beckmann]

Package: redmine
Version: 3.2.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + redmine-plugin-custom-css

Hi,

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

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

  Setting up redmine (3.2.0-2) ...
  Please configure your config/database.yml first
  dbconfig-common: writing config to 
/etc/dbconfig-common/redmine/instances/default.conf
  
  Creating config file /etc/dbconfig-common/redmine/instances/default.conf with 
new version
  
  Creating config file /etc/redmine/default/database.yml with new version
  creating database redmine_default: success.
  verifying database redmine_default exists: success.
  /usr/lib/ruby/vendor_ruby/molinillo/dependency_graph.rb:109:in `add_vertex': 
wrong number of arguments (3 for 2) (ArgumentError)
from /usr/lib/ruby/vendor_ruby/bundler/resolver.rb:194:in `block in 
initialize'
from /usr/lib/ruby/vendor_ruby/bundler/resolver.rb:194:in `initialize'
from /usr/lib/ruby/vendor_ruby/bundler/resolver.rb:182:in `new'
from /usr/lib/ruby/vendor_ruby/bundler/resolver.rb:182:in `resolve'
from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:198:in `resolve'
from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:137:in `specs'
from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:182:in `specs_for'
from /usr/lib/ruby/vendor_ruby/bundler/definition.rb:171:in 
`requested_specs'
from /usr/lib/ruby/vendor_ruby/bundler/environment.rb:18:in 
`requested_specs'
from /usr/lib/ruby/vendor_ruby/bundler/runtime.rb:13:in `setup'
from /usr/lib/ruby/vendor_ruby/bundler.rb:92:in `setup'
from /usr/lib/ruby/vendor_ruby/bundler/setup.rb:8:in `'
from /usr/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in 
`require'
from /usr/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in 
`require'
  dpkg: error processing package redmine (--configure):
   subprocess installed post-installation script returned error exit status 1


This was observed while installing the dependencies of package
redmine-plugin-custom-css in preparation of a piuparts test on that
package.


cheers,

Andreas


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

Bug#815624: mate-dock-applet: fails to install: mate-dock-applet.postinst: glib-compile-schemas: not found

[Andreas Beckmann]

Package: mate-dock-applet
Version: 0.67-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Selecting previously unselected package mate-dock-applet.
  (Reading database ... 
(Reading database ... 27152 files and directories currently installed.)
  Preparing to unpack .../mate-dock-applet_0.67-2_amd64.deb ...
  Unpacking mate-dock-applet (0.67-2) ...
  Processing triggers for libglib2.0-0:amd64 (2.46.2-3) ...
  Setting up mate-dock-applet (0.67-2) ...
  /var/lib/dpkg/info/mate-dock-applet.postinst: 8: 
/var/lib/dpkg/info/mate-dock-applet.postinst: glib-compile-schemas: not found
  dpkg: error processing package mate-dock-applet (--configure):
   subprocess installed post-installation script returned error exit status 127
  Errors were encountered while processing:
   mate-dock-applet


cheers,

Andreas


mate-dock-applet_0.67-2.log.gz
Description: application/gzip

Bug#815623: mpich: Description should mention MPI-3 and possibly MPI_THREAD_MULTIPLE

[Michael Banck]

Package: mpich
Version: 3.2-6
Severity: wishlist

Hi,

The MPICH package description still says "implementation of the Message
Passing Interface (MPI) standard (both MPI-1 and MPI-2)".  However, as
of some time now I think, MPICH supports MPI-3 as well.

As an extra kick against OpenMPI, it could also mention that it supports
the MPI_THREAD_MULTIPLE option - I "have" to use MPICH for some of my
packages as OpenMPI's MPI_THREAD_MULTIPLE implementation is buggy and
(rightfully) not enabled in Debian.


Michael

Bug#811441: insserv: warn about dependencies in ignore mode

[Felipe Sateler]

Package: insserv
Version: 1.14.0-5.2
Followup-For: Bug #811441

Hi,

I have uploaded an NMU including the earlier patch to DELAYED/10. Please
find a debdiff attached.



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

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

Versions of packages insserv depends on:
ii  libc6  2.21-9

insserv recommends no packages.

Versions of packages insserv suggests:
pn  bootchart2  

-- no debconf information
diff -Nru insserv-1.14.0/debian/changelog insserv-1.14.0/debian/changelog
--- insserv-1.14.0/debian/changelog	2016-01-27 14:45:31.0 -0300
+++ insserv-1.14.0/debian/changelog	2016-02-22 21:22:09.0 -0300
@@ -1,3 +1,11 @@
+insserv (1.14.0-5.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not suppress warnings on force mode
+(Closes: #811441)
+
+ -- Felipe Sateler   Mon, 22 Feb 2016 21:22:07 -0300
+
 insserv (1.14.0-5.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru insserv-1.14.0/debian/patches/series insserv-1.14.0/debian/patches/series
--- insserv-1.14.0/debian/patches/series	2016-01-26 20:50:19.0 -0300
+++ insserv-1.14.0/debian/patches/series	2016-02-22 20:58:34.0 -0300
@@ -12,3 +12,4 @@
 160_manual_page_update.patch
 170_undeclared_extension.patch
 180_MAXSYMLINKS.patch
+warn_in_ignore_mode.patch
diff -Nru insserv-1.14.0/debian/patches/warn_in_ignore_mode.patch insserv-1.14.0/debian/patches/warn_in_ignore_mode.patch
--- insserv-1.14.0/debian/patches/warn_in_ignore_mode.patch	1969-12-31 21:00:00.0 -0300
+++ insserv-1.14.0/debian/patches/warn_in_ignore_mode.patch	2016-02-22 21:04:31.0 -0300
@@ -0,0 +1,16 @@
+Description: warn about dependencies in ignore mode
+Author: Felipe Sateler 
+Bug-Debian: https://bugs.debian.org/811441
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/insserv.c
 b/insserv.c
+@@ -3074,7 +3074,7 @@ int main (int argc, char *argv[])
+ 		 * Use information from symbolic link structure to
+ 		 * check if all services are around for this script.
+ 		 */
+-		if (isarg && !ignore) {
++		if (isarg) {
+ 			boolean ok = true;
+ 			if (del)
+ 			ok = chkdependencies(service);

Bug#814664: [Pkg-roundcube-maintainers] Bug#814664: Incorrect hardcoded php-auth and other dependencies

[Sandro Knauß]

Hey,

thanks for reporting this bug. I actually try to use pkg-php-tools, but don't 
get the same result like you.

I installed the composer.json-dist to roundcure-core package and than run
override_dh_phpcomposer:
 dh_phpcomposer --sourcedirectory=$(CURDIR)/debian/roundcube-core/usr/share/
roundcube

but with that I get:
phpcomposer:Debian-require=php5-common, php5-common (>= 5.3.7), php-roundcube-
plugin-installer (>= 0.1.6), php-roundcube-plugin-installer (<< 0.2~~), php-
auth-sasl (>= 1.0.6), php-auth-sasl (<< 1.1~~), php-net-idna2 (>= 0.1.1), php-
net-idna2 (<< 0.2~~), php-net-sieve (>= 1.3.4), php-net-sieve (<< 1.4~~), php-
mail-mime (>= 1.9.0), php-mail-mime (<< 1.10~~), php-net-smtp (>= 1.7.1), php-
net-smtp (<< 1.8~~), php-patchwork-utf8 (>= 1.2.3), php-patchwork-utf8 (<< 
1.3~~)
phpcomposer:Debian-require-dev=php-crypt-gpg, phpunit
phpcomposer:Debian-suggest=php-net-ldap2, php-net-ldap3

do i miss an option for  dh_phpcomposer to get rid of these << XX~~ parts? Or 
are they needed?

regards,

sandro


--
Am Saturday 13 February 2016, 15:43:06 schrieb David Prévot:
> Package: roundcube-core
> Version: 1.1.4+dfsg.1-1
> Severity: important
> 
> Hi,
> 
> According to composer.json-dist, there shouldn’t be any php-auth
> dependency. Instead, it should read something like:
> 
> Depends: php-auth-sasl (>= 1.0.6),
>  php-net-idna2 (>= 0.1.1),
>  php-net-sieve (>= 1.3.4),
>php-mail-mime (>= 1.9.0),
>php-net-smtp (>= 1.4.2),
>php-patchwork-utf8 (>= 1.2.3)
> Suggests: php-net-ldap2 (>= 2.1.0),
>   php-net-ldap3
> 
> pkg-php-tools may be useful to translate those dependencies
> automatically, and to keep them up to date.
> 
> Since php-auth “is not maintained” [0], we’d like to get read of it
> ASAP, thus the important severity.
> 
>   0: https://pear.php.net/package/Auth
> 
> I’ll open a serious bug against php-auth, and block it by this one. You
> may wish to update your package before it gets auto-removed.
> 
> Regards
> 
> David


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

Bug#815110: tracker.debian.org: please use plain images (rather than web fonts) as icons

[Tiago Ilieve]

Hi,

Worth mentioning that GitHub itself has stopped using icon fonts,
delivering Octicons with SVG[1]. They even figured that using SVG is
actually (a little bit) faster than the previous approach.

Regards,
Tiago.

[1]: https://github.com/blog/2112-delivering-octicons-with-svg

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#815622: Postfix fails to start after apt-get upgrade

[James Cloos]

Package: postfix
Version: 3.0.3-1
Severity: important

After running apt-get upgrade, postfix fails to start due to this:

postmulti: fatal: instance /etc/postfix, shlib_directory=/usr/lib/postfix 
conflicts with instance /etc/postfix, daemon_directory=/usr/lib/postfix

Neither shlib_directory nor daemon_directory are mentioned in my /etc/postfix,
and I had not been using multi at all on this box.

If the new init script cannot handle having shlib_directory and daemon_directory
be identical, the defaults should not have them identical.

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

Kernel: Linux 3.2.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: sysvinit (via /sbin/init)

Versions of packages postfix depends on:
ii  adduser3.113+nmu3
ii  cpio   2.11+dfsg-5
ii  debconf [debconf-2.0]  1.5.58
ii  dpkg   1.18.4
ii  libc6  2.21-9
ii  libdb5.3   5.3.28-11
ii  libicu55   55.1-7
ii  libsasl2-2 2.1.26.dfsg1-14+b1
ii  libsqlite3-0   3.11.0-1
ii  libssl1.0.21.0.2f-2
ii  lsb-base   9.20160110
ii  netbase5.3
ii  ssl-cert   1.0.37

Versions of packages postfix recommends:
ii  python3  3.5.1-1

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]8.1.2-0.20160123cvs-2
pn  dovecot-common 
ii  emacs24-nox [mail-reader]  24.5+1-6+b1
ii  libsasl2-modules   2.1.26.dfsg1-14+b1
ii  mutt [mail-reader] 1.5.24-1+b1
ii  postfix-cdb3.0.3-1
ii  postfix-doc3.0.3-1
pn  postfix-ldap   
pn  postfix-mysql  
ii  postfix-pcre   3.0.3-1
ii  postfix-pgsql  3.0.3-1
ii  procmail   3.22-25
pn  resolvconf 
ii  s-nail [mail-reader]   14.8.6-1
pn  sasl2-bin  
pn  ufw

-- debconf information:
  postfix/sqlite_warning:
  postfix/protocols: all
  postfix/relayhost:
  postfix/procmail: true
  postfix/mynetworks: 127.0.0.0/8 [::1]/128
  postfix/root_address:
  postfix/tlsmgr_upgrade_warning:
  postfix/mailbox_limit: 0
  postfix/recipient_delim: +
* postfix/main_mailer_type: Internet Site
  postfix/mydomain_warning:
  postfix/bad_recipient_delimiter:
  postfix/destinations: globe.jhcloos.com, localhost.jhcloos.com, localhost
  postfix/not_configured:
  postfix/kernel_version_warning:
  postfix/retry_upgrade_warning:
* postfix/mailname: globe.jhcloos.com
  postfix/rfc1035_violation: false
  postfix/chattr: false
  postfix/relay_restrictions_warning:

Bug#815542: license-reconcile: Please add support for the HTTPS link to the format

[gregor herrmann]

On Mon, 22 Feb 2016 10:16:51 +0100, Petter Reinholdtsen wrote:

> Package: license-reconcile
> Version: 0.9
> Severity: important
> 
> The license-reconcile script do not understand the https URL in the
> format string:
> 
> % license-reconcile
> FormatSpec: Cannot recognize format: Format: 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ at 
> /usr/share/perl5/Debian/LicenseReconcile/App.pm line 222.

Fixed in git.
Nicholas, do you have time to check my changes?
(I also made changes for #703498.)

> CopyrightParsing: Invalid field given (Source) at 
> /usr/share/perl5/Debian/Copyright.pm line 131.

That's in libdebian-copyright-perl.

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Element of Crime: Die letzte U-Bahn geht später


signature.asc
Description: Digital Signature

Bug#763963: systemd errors went away when upgraded to linux-image-3.16-2-686-pae kernel image

[Jorge Pérez]

On Sat, 11 Oct 2014 10:57:13 +0530 Manish  wrote:
> Hi,
>
> systemd errors went away after I upgraded to linux-image-3.16-2-686-pae
> kernel image.
>
> apt-get install linux-image-3.16-2-686-pae
>
> Earlier when I did "apt-get dist-upgrade", it was using
> linux-image-2.6.32-5-686 and hence it was giving errors as it is
> mentioned in systemd README file that systemd requires Linux kernel >=
> 3.0.
>
> I think apt-get dist-upgrade should upgrade the kernel image from 2.6 to
> 3.0 as part of dependency to systemd.
>
> Now uname -r command on my system says:
> Linux debian 3.16-2-686-pae #1 SMP Debian 3.16.3-2 (2014-09-20) i686
> GNU/Linux
>
> For me this bug is now resolved after upgrade to kernel 3.16. You may
> now please close this bug.
>
> Thanks and Regards,
> Manish Mohania
>
>
>

Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]

[Alexandre Rossi]

Hello,

>> > As this is Linux 4.3 and not 4.4, I guess this is a different problem
>> > though. Alexandre, where you able to capture the stack trace? I’d submit
>> > a new bug report with this.
>>
>> Here is a photo. Please ping me if you need to test some debugging patches.
>
> It looks like the problem occurs in blk_post_runtime_resume().  Since
> there have been recent changes to this routine, it's hard to tell
> whether you're using the most up-to-date code.
>
> In particular, the first few lines of blk_post_runtime_resume() in
> block/blk-core.c should look like this:
>
> void blk_post_runtime_resume(struct request_queue *q, int err)
> {
> if (!q->dev)
> return;
>
> The test was introduced by commit 4fd41a8552af ("SCSI: Fix NULL pointer
> dereference in runtime PM"), which was added to the mainline kernel
> between 4.3 and 4.4.  I don't know what the commit ID would be for a
> .stable kernel.

Okay now I've tried with 4.4. The oops does not occur. So this is
fixed for me in 4.4.

If there is interest in backporting to 4.3, 13b438914341 ("SCSI: fix
crashes in sd and sr runtime PM") is not enough to backport. Something
in 4.4, most probably 4fd41a8552af ("SCSI: Fix NULL pointer
dereference in runtime PM") is also needed.

Thanks a lot,

Alex

Bug#813881: [PATCH 1/1 v3] ARM: dts: imx6dlq-wandboard-revb1.dts: use unique model id

[Roger Shimizu]

Dear Ben,

On Sun, Feb 14, 2016 at 9:59 PM, Roger Shimizu  wrote:
> Dear Kernel Maintainer,
>
> On Sun, Feb 14, 2016 at 6:01 PM, Heinrich Schuchardt  
> wrote:
>> Shawn Guo the Linux kernel maintainer of ARM/Freescale IMX / MXC ARM
>> architecture has accepted my appended patch 0001-ARM... to change the
>> model id of the Wandboard Quad Rev B1 and the Wandboard Dual Rev B1.
>>
>> See
>> https://lkml.org/lkml/2016/2/14/34
>> https://lkml.org/lkml/2016/2/7/270
>>
>> I suggest to add the patch to
>> linux-source-4.3 (debian/patches/bugfix/arm)
>> and to update flash-kernel (patch 0001-db... appended).
>
> I also have a few device-tree "fixes", as well as "for-next" applied
> by upstream sub-system maintainer.
> For "fixes", some of those're already got merged into linus's 4.5-rc
> tree, and will, AFAIK, be backported to each related/affected stable
> kernel, and finally reach Debian's stable kernel; for "for-next", it's
> waiting for the next merge window (to say, 4.6).
>
> I also want to know what's debian's kernel policy [0] on backporting
> those device-tree file.
>
> Please help to clarify. Thank you!
>
> [0]: https://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

Could you help to comment on this, please?

If you think backporting those device-tree to "master"/"sid" is fine,
I can handle both the patch mention in this thread and a few
Linkstation device-tree patch I submitted.
Thank you!

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#815409: qemu-img create -f qcow2 ... segfaults on mips

[Hilko Bengen]

Dear qemu maintainers,

gdb on mips/unstable does not seem to like me, but I think that I may
have traced the source of this segfault to somewhere inside
qemu_coroutine_create (the second breakpoint is at the end of
qemu_coroutine_create). See below for what I tried.

Cheers,
-Hilko

,
| $ gdb --args ./qemu-img create -f qcow2 blank-disk-1s.qcow2 10
| GNU gdb (Debian 7.10-1+b1) 7.10
| Copyright (C) 2015 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later 
| This is free software: you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
| and "show warranty" for details.
| This GDB was configured as "mips-linux-gnu".
| Type "show configuration" for configuration details.
| For bug reporting instructions, please see:
| .
| Find the GDB manual and other documentation resources online at:
| .
| For help, type "help".
| Type "apropos word" to search for commands related to "word"...
| Reading symbols from ./qemu-img...done.
| (gdb) b qemu_coroutine_create
| Breakpoint 1 at 0x4e2088: file 
/home/bengen/qemu-2.5+dfsg/util/qemu-coroutine.c, line 45.
| (gdb) r 
| Starting program: /home/bengen/qemu-2.5+dfsg/qemu-build/qemu-img create -f 
qcow2 blank-disk-1s.qcow2 10
| warning: GDB can't find the start of the function at 0x77fc6c30.
| 
| GDB is unable to find the start of the function at 0x77fc6c30
| and thus can't determine the size of that function's stack frame.
| This means that GDB may be unable to access that stack frame, or
| the frames below it.
| This problem is most likely caused by an invalid program counter or
| stack pointer.
| However, if you think GDB should simply search farther back
| from 0x77fc6c30 for code which looks like the beginning of a
| function, you can increase the range of the search using the `set
| heuristic-fence-post' command.
| [Thread debugging using libthread_db enabled]
| Using host libthread_db library "/lib/mips-linux-gnu/libthread_db.so.1".
| warning: GDB can't find the start of the function at 0x77fc75e4.
| Formatting 'blank-disk-1s.qcow2', fmt=qcow2 size=10 encryption=off 
cluster_size=65536 lazy_refcounts=off refcount_bits=16
| 
| Breakpoint 1, qemu_coroutine_create (entry=0x41e048 )
| at /home/bengen/qemu-2.5+dfsg/util/qemu-coroutine.c:45
| 45  {
| (gdb) b 79
| Breakpoint 2 at 0x4e20f8: file 
/home/bengen/qemu-2.5+dfsg/util/qemu-coroutine.c, line 79.
| (gdb) c
| Continuing.
| warning: GDB can't find the start of the function at 0x76405e10.
| 
| Program received signal SIGSEGV, Segmentation fault.
| 0x76405e10 in ?? ()
`

Bug#815554: [Aptitude-devel] Bug#815554: aptitude: truncated hostname in header line (regression)

[Manuel A. Fernandez Montecelo]

2016-02-22 23:12 Vincent Lefevre:

On 2016-02-22 21:22:44 +, Manuel A. Fernandez Montecelo wrote:

I had to do some changes to the size due to #810221 -- the fields Broken
and Download size are more important than host for most people, I guess.


I don't think they need much precision (3 or 4 digits is enough).
Also note that the host is truncated even when there is no size
information. For instance:

aptitude 0.7.6 @ cven

and that's all with a 80-column terminal!


I don't recall the details, but I think that aptitude/cwidget reserve
the space even if the other fields don't have any text in them, and
there are fields for "Broken", "Will use/free space", and "DL Size".

The minimum for the hostname should be 8, expandable but not shrinkable,
but either it's not doing that or it overcommits space available and
then shinks anyway.



Some people like the hostname being there, but I am still wondering if
it was an error to honour that request and enable it by default, because
we have had 2 reports because of it in a short time.


I think that it is nice to have it since there is space for it
(see above). I also have the hostname in my window title, but
when I run SSH in screen, it may or may not be updated, depending
on the context. Having it in aptitude is more informative.


Noted.



Due to the rules of creating columns in aptitude/cwidget, this is a bit
of a mess (it needs to reserve space beforehand even if the line appears
empty).


How about defining only one column and build the line yourself?


In any case, something has to give, and it's impossible to
support largish hostnames in 80-width characters anyway.


I get:

aptitude 0.7.6 @ cven  Will free 357 kB of disk spa DL Size: 38.8 MB

I don't understand why both the hostname and "disk space" are
truncated. Also, instead of "Will free 357 kB of disk spa",
which should be "Will free 357 kB of disk space", how about:

Disk: -357 kB

(with the sign - for "free" and + for "use").

Note that "space" and "size" are redundant with the kB/MB/... size unit.
Instead of "DL Size:", you could write "DL:" or "Download:".


Actually, when fiddling with the above I thought about rephrasing
specially the longer "Will free...", maybe somethink like "Disk after
install: blah", "Disk usage change: blah", "Disk usage: blah" or
similar.  Not much shorter but it will probably be enough.  I am not
sure if just "Disk" is descriptive enough for new/casual users.

I didn't go ahead to try to not make it worse, or to make possibly
unnecessary changes that might unplease some users more avert to change
in general, or the new phrases in particular.

"DL" by itself is not very descriptive for new/casual users, and
"Download" is 8 chars (in English) vs 7 of "DL Size", so it doesn't help
with the length thing (although it is clearer).


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#815621: debmake: Handle gpl with autoconf exception better when checking copyright file?

[Petter Reinholdtsen]

Package: debmake
Version: 4.2.2-1

When I use 'debmake -k' on the zfsonlinux source, I see this issue:

Pattern #23: config/*
  File: config/ltmain.sh
config/config.guess
config/depcomp
config/missing
config/config.sub
- GPL-2+ with autoconf exception
+ GPL-2.0+ with multiple exceptions XXX FIXME XXX

What is the story behind the FIXME and can the program be exctended to
understand this fairly normal special case?

-- 
Happy hacking
Petter Reinholdtsen

Bug#815620: addsubstvar fails if there are utf characters in the substvar file

[Joachim Breitner]

Package: debhelper
Version: 9.20160115
Severity: important

Hi,

A few (Haskell) packages fail to build because addsubstvar in Dh_Lib.pm,
which uses grep, falls over unicode characters in existing substvar
lines. It makes lines like
Binary file debian/libghc-gitit-doc.substvars matches
appear in the substvar file, which obviously breaks.

The fix is simple: In Dh_Lib.pm, replace calls to "grep -s -v" with
"grep -a -s -v".

Greetings,
Joachim


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

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

Versions of packages debhelper depends on:
ii  autotools-dev20150820.1
ii  binutils 2.26-4
ii  dh-strip-nondeterminism  0.015-1
ii  dpkg 1.18.4
ii  dpkg-dev 1.18.4
ii  file 1:5.25-2
ii  libdpkg-perl 1.18.4
ii  man-db   2.7.5-1
ii  perl 5.22.1-7
ii  po-debconf   1.0.19

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#815551: aptitude: safe-upgrade removes manually installed package if dependency is on hold

[Manuel A. Fernandez Montecelo]

Hi Sven,

2016-02-22 10:57 Sven Joachim:

Package: aptitude
Version: 0.7.6-1
Severity: important

I have the packages iceweasel and libwine on hold, and all of a sudden
"aptitude safe-upgrade" declares packages that depend on them as unused
and wants to remove them:

,
| $ LANG=C aptitude -s -V -D safe-upgrade
| Resolving dependencies...
| The following packages will be REMOVED:
|   iceweasel-l10n-de{u} [1:38.6.1esr-1~deb8u1]  wine{u} [1.6.2-22]  wine32{u} 
[1.6.2-22] (D: wine)
| 0 packages upgraded, 0 newly installed, 3 to remove and 6 not upgraded.
| Need to get 0 B of archives. After unpacking 1014 kB will be freed.
|
| Note: Using 'Simulate' mode.
| Do you want to continue? [Y/n/?]
| Would download/install/remove packages.
`

None of these three packages is marked as manually installed:

,
| $ LANG=C aptitude versions libwine wine wine32 iceweasel iceweasel-l10n-de
| Package iceweasel:
| ih 38.6.1esr-1~deb8u1  100
| ph 44.0.2-1 unstable 500
| ph 45.0~b5-1 experimental 101
|
| Package iceweasel-l10n-de:
| i  1:38.6.1esr-1~deb8u1  100
| p  1:44.0.2-1 unstable 500
| p  1:45.0~b5-1 experimental 101
|
| Package libwine:
| ihA 1.6.2-22  100
| phA 1.8.1-2 unstable 500
|
| Package wine:
| i  1.6.2-22  100
| p  1.8.1-2 unstable 500
|
| Package wine32:
| i  1.6.2-22  100
| p  1.8.1-2 unstable 500
`

A workaround is to put the affected packages on hold as well, but this
ought not to be necessary.


Have you used 0.7.5 until now and this only happens after upgrading
aptitude to .6?  Did something else happen since the last time that you
ran safe-upgrade, e.g. upgrade of apt?

Also, if you hold and then unhold wine and iceweasel-l10n-de, it keeps
trying to remove them as unused, or did it only happen the first time
(before marking them as hold)?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#815554: [Aptitude-devel] Bug#815554: aptitude: truncated hostname in header line (regression)

[Vincent Lefevre]

On 2016-02-22 21:22:44 +, Manuel A. Fernandez Montecelo wrote:
> I had to do some changes to the size due to #810221 -- the fields Broken
> and Download size are more important than host for most people, I guess.

I don't think they need much precision (3 or 4 digits is enough).
Also note that the host is truncated even when there is no size
information. For instance:

aptitude 0.7.6 @ cven

and that's all with a 80-column terminal!

> Some people like the hostname being there, but I am still wondering if
> it was an error to honour that request and enable it by default, because
> we have had 2 reports because of it in a short time.

I think that it is nice to have it since there is space for it
(see above). I also have the hostname in my window title, but
when I run SSH in screen, it may or may not be updated, depending
on the context. Having it in aptitude is more informative.

> Due to the rules of creating columns in aptitude/cwidget, this is a bit
> of a mess (it needs to reserve space beforehand even if the line appears
> empty).

How about defining only one column and build the line yourself?

> In any case, something has to give, and it's impossible to
> support largish hostnames in 80-width characters anyway.

I get:

aptitude 0.7.6 @ cven  Will free 357 kB of disk spa DL Size: 38.8 MB

I don't understand why both the hostname and "disk space" are
truncated. Also, instead of "Will free 357 kB of disk spa",
which should be "Will free 357 kB of disk space", how about:

Disk: -357 kB

(with the sign - for "free" and + for "use").

Note that "space" and "size" are redundant with the kB/MB/... size unit.
Instead of "DL Size:", you could write "DL:" or "Download:".

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

Bug#697362: debhelper: [dh_installudev] please automatically generate `udevadm trigger` calls

[Michael Biebl]

Am 22.02.2016 um 20:37 schrieb Niels Thykier:
> On Fri, 04 Jan 2013 12:38:31 +0100 Luca Capello  wrote:
>> Package: debhelper
>> Version: 9.20120909
>> Severity: wishlist
>> File: /usr/bin/dh_installudev
>> Usertags: debian-packaging
>>
>> Hi there!
>>
>> When a package installs udev rules, these not automatically applied if
>> the device is built-in (like fingerprint readers), since it is never
>> plugged in (obviously, except if the computer is rebooted).  Thus
>> package.postinst must call `udevadm trigger` according to the udev's
>> maintainer's explanation at:
>>
>>   
>>
>> While `udevadm trigger` could be called without options, IMHO it is
>> preferable to limit its call(s) for the device(s) the package supports.
>> In some cases, the number of the devices can be quite a lot (e.g.
>> libfprint0 supports 17 of them), thus having an automatic way to
>> generate these calls from the udev rules would be preferable.
>>
>> I would be glad to provide a patch, but I am a bit busy ATM.
>>
>> Thx, bye,
>> Gismo / Luca
>>
>> [...]
> 
> Hi systemd/udev maintainers,
> 
> Is this something we can solve by using dpkg file triggers (or an
> activate-noawait trigger)?

"udevadm trigger" should not be run unconditionally as it can have side
effects.
If it has to be run at all, it should  be limited to packages which need
it and be done for the corresponding subsystem only.
So I think neither having dh_installudev generate that by default nor
having a dpkg (file) trigger is a good idea.

Michael



-- 
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#815616: [PATCH] copyright: correct license of japanese font

[Arnout Vandecappelle (Essensium/Mind)]

japanese_230_50.qpf is generated from the helvetica sources, so it is
covered by the same license. Cfr. lib/fonts/README in the source tree.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) 
---
 debian/copyright | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index 2785787..44f4871 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -415,7 +415,7 @@ Files: src/3rdparty/iaccessible2/idl/*
 Copyright: 2006 IBM Corporation
 License: BSD-3-clause
 
-Files: lib/fonts/helvetica*
+Files: lib/fonts/helvetica* lib/fonts/japanese_230_50.qpf
 Copyright: 1984-1989, 1994 Adobe Systems Incorporated.
1988, 1994 Digital Equipment Corporation.
 License: Adobe
@@ -558,7 +558,7 @@ License: Courier
  ARE GIVEN, WHETHER EXPRESS OR IMPLIED INCLUDING, BUT LIMITED TO THE IMPLIED
  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 
-Files: lib/fonts/micro_40_50.qpf lib/fonts/japanese_230_50.qpf 
lib/fonts/fixed_120_50.qpf lib/fonts/fixed_70_50.qpf
+Files: lib/fonts/micro_40_50.qpf lib/fonts/fixed_120_50.qpf 
lib/fonts/fixed_70_50.qpf
 Copyright: -
 License: public-domain
  A public domain font. Share and enjoy. http://www.X.org
-- 
2.7.0

Bug#815619: myspell-de-de: subtraktiv regarded as an error, substraktiv as correct

[forwarder2]

Package: myspell-de-de
Version: 20131206-5
Severity: minor
Tags: upstream

Dear Maintainer,

the problem was encountered in libreoffice. The spell check had an issue with 
"subtraktiv", which is a correct word, but not with "substraktiv" which is a 
common misspelling of it. Furthermore, 
"Substraktion" is regarded as correct, which is wrong;
"Subtraktion" is regarded as correct, which it is;
"substrahieren" is regarded as correct, which is wrong;
"subtrahieren" is also regarded as correct, which is correct.

I checked the "Duden" online, as I believe I learned the spellings with two "s"
at school.

Sorry I don't have the time right now to check out the current "testing" and 
upstream versions.

Greetings-
FM

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

-- System Information:
Debian Release: 8.3
  APT prefers stable
  APT policy: (900, 'stable'), (800, 'testing') - only kernel is from "testing".
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages myspell-de-de depends on:
ii  dictionaries-common [openoffice.org-updatedicts]  1.23.17

myspell-de-de recommends no packages.

Versions of packages myspell-de-de suggests:
pn  openoffice.org  

-- no debconf information

Bug#814038: aptitude: Provide a way to reverse order with any of the available sorting criterias

[Manuel A. Fernandez Montecelo]

Hi Axel,

2016-02-14 15:20 Axel Beckert:

Control: severity -1 minor
Control: retitle -1 aptitude: Document how to reverse the order of the 
available sorting criterias

Hi,

Manuel A. Fernandez Montecelo wrote:

>Currently [S], Aptitude::UI::Default-Sorting and --sort allow a bunch of
>sorting criterias, e.g. "installsize". "installsize" sorts the smallest
>packages first. Nevertheless there currently
>seems no way to sort packages so that the biggest packages come first.
>
>While e.g. "aptitude search --sort installsize '~i' | tac" is a
>workaround on the commandline, there's no similar workaround for
>anything affecting the TUI interface.

I haven't checked so I don't know if it works 100%, and I don't know if
it's documented, but I think that prepending a ~ reverses the sort
policy direction, so "~installsize" should sort with the
largest-unpacked-size packages first.


Thanks! That's what I was looking for!

So it's solely a documentation issue. Raising severity from wishlist
to minor then and retitling the bug report accordingly.


It's not documented in the man page, but then again in the --sort
section doesn't contain the policy names and it refers to the on-line
guide (which in my opinion is good, to not repeat information which can
easily go out of sync).

 -O , --sort 
 
Specify the order in which output from the search and versions

commands should be displayed. For instance, passing “installsize”
for  will list packages in order according to their size
when installed (see the section “Customizing how packages are
sorted” in the aptitude reference manual for more information).

The default sort order is name,version.


And in the User's Manual (using the on-line version URLs):

 http://aptitude.alioth.debian.org/doc/en/ch02s05s01.html

 Customizing how packages are sorted

 By default, packages in the package list or in the output of aptitude
 search are sorted by name. However, it is often useful to sort them
 according to different criteria (for instance, package size), and
 aptitude allows you to do just that by modifying the sorting policy.

 Like the grouping policy described in the previous section, the
 sorting policy is a comma-separated list. Each item in the list is the
 name of a sorting rule; if packages are “equal” according to the first
 rule, the second rule is used to sort them, and so on. Placing a tilde
 character (~) in front of a rule reverses the usual meaning of that
 rule. For instance, priority,~name will sort packages by priority, but
 packages with the same priority will be placed in reverse order
 according to name.


So it's already documented and I am satisfied with it as it is, although
I don't know if you would prefer to make it more prominent.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#802523: psocksxx: FTBFS: You made dpkg-gensymbols sad

[Gianfranco Costamagna]

Hi
Do you need a sponsor for this?
Let me know
Gianfranco
On Sat, 21 Nov 2015 05:50:18 +0100 =?ISO-8859-1?Q?J=F6rg_Frings-F=FCrst?= 
 wrote:
> Hola Eriberto,
> 
> thanks for your patch.
> 
> I have the new upstream release ready and uploaded to mentors.
> My mentor is checking some libstdc++ transition issues.
> 
> 
> Many thanks again.
> 
> Am Freitag, den 20.11.2015, 12:24 -0200 schrieb Eriberto Mota:
> > tags 802523 patch
> > thanks
> > 
> > 
> > Hi,
> > 
> > The attached patch will fix the bug.
> > 
> > Regards,
> > 
> > Eriberto
> 
> 
> CU
> Jörg
> 
> -- 
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key    : 8CA1D25D
> CAcert Key S/N : 0E:D4:56
> 
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
> 
> Jörg Frings-Fürst
> D-54526 Niederkail
> 
> Threema: SYR8SJXB
> 
> IRC: j_...@freenode.net
>  j_...@oftc.net
> 
> My wish list: 
>  - Please send me a picture from the nature at your home.
> 
> 
> 

Sent from Yahoo Mail on Android

Bug#815618: ovmf: Please someone create a DFSG-free ovmf variant

[Francesco Poli (wintermute)]

Package: ovmf
Version: 0~20160104.c2a892d7-1
Severity: wishlist

Hello.

As far as I know, package ovmf is needed in order to create and
run a virtual UEFI machine. Unfortunately, ovmf is non-free, since the
included Intel FAT file system driver has "additional terms" that
restrict redistribution and use to the implementation of (U)EFI
specifications.
As documented in the debian/copyright file, the files under the
non-free license are FatBinPkg/* and FatPkg/* .

I am not aware of any DFSG-free alternative or any ovmf variant with
the Intel FAT driver replaced by some BSD-licensed DFSG-free FAT driver.
Do you know of any such alternative?

Perhaps the FAT driver in some *BSD kernel could be adapted, in order
to create a DFSG-free ovmf fork. I hope that someone with the appropriate
expertise will volunteer to create this fork, so that we can finally
have a package in Debian main to support virtual UEFI machines.

I am filing this bug report in order to draw attention on this issue,
which often seems to go unnoticed. In other words, I hope that someone
will soon look at ovmf bug reports, stumble upon this report, and
volunteer to solve this issue.
Please do not close the bug report. Thanks.


N.B.:
Please note that the additional restrictions for the Intel FAT are
caused by the use of the FAT32 specifications by Microsoft: hence
any volunteer should refrain from reading or consulting these
specifications.
Needless to say, the Intel FAT driver should not be studied, either,
otherwise the replacement driver would be a derivative of the Intel
one and the same non-free restrictions would apply to the replacement.

Bug#815617: copyright: wrong license for japanese_230_50.qpf

[Arnout Vandecappelle]

Source: qtbase-opensource-src
Severity: minor
Tags: patch

japanese_230_50.qpf is generated from the helvetica sources, so it is
covered by the same license. Cfr. lib/fonts/README in the source tree.


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

>From e0cf2077d5c254a91e2500f42eb4aa2df07bf2c9 Mon Sep 17 00:00:00 2001
From: "Arnout Vandecappelle (Essensium/Mind)" 
Date: Mon, 22 Feb 2016 23:16:07 +0100
Subject: [PATCH] copyright: correct license of japanese font

japanese_230_50.qpf is generated from the helvetica sources, so it is
covered by the same license. Cfr. lib/fonts/README in the source tree.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) 
---
 debian/copyright | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index 2785787..44f4871 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -415,7 +415,7 @@ Files: src/3rdparty/iaccessible2/idl/*
 Copyright: 2006 IBM Corporation
 License: BSD-3-clause
 
-Files: lib/fonts/helvetica*
+Files: lib/fonts/helvetica* lib/fonts/japanese_230_50.qpf
 Copyright: 1984-1989, 1994 Adobe Systems Incorporated.
1988, 1994 Digital Equipment Corporation.
 License: Adobe
@@ -558,7 +558,7 @@ License: Courier
  ARE GIVEN, WHETHER EXPRESS OR IMPLIED INCLUDING, BUT LIMITED TO THE IMPLIED
  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 
-Files: lib/fonts/micro_40_50.qpf lib/fonts/japanese_230_50.qpf lib/fonts/fixed_120_50.qpf lib/fonts/fixed_70_50.qpf
+Files: lib/fonts/micro_40_50.qpf lib/fonts/fixed_120_50.qpf lib/fonts/fixed_70_50.qpf
 Copyright: -
 License: public-domain
  A public domain font. Share and enjoy. http://www.X.org
-- 
2.7.0

Bug#815613: wheezy-pu: package clamav/0.99+dfsg-0+deb7u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2016-02-22 at 23:18 +0100, Sebastian Andrzej Siewior wrote:
> In order to address the Sparc fallout in the Wheezy update (#814544),
> here is the fix. This patch is also part of last unstable upload
> (0.99+dfsg-2) and pending for Jessie (0.99+dfsg-0+deb8u2, #815598).

Please go ahead.

Regards,

Adam

Bug#815616: copyright: wrong license for japanese_230_50.qpf

[Arnout Vandecappelle]

Source: qtbase-opensource-src
Severity: minor
Tags: patch

japanese_230_50.qpf is generated from the helvetica sources, so it is
covered by the same license. Cfr. lib/fonts/README in the source tree.


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#815615: ganglia-monitor: Improper user/group removal in maintainer scripts

[Dave Rawks]

Package: ganglia-monitor
Version: 3.6.0-6
Severity: important
Tags: patch

Dear Maintainer,

The ganglia-monitor package has some troublesome user/group management routines 
in it's
maintainer scripts.

Contrary to the recommended practice here: 
https://wiki.debian.org/AccountHandlingInMaintainerScripts

The maintainer scripts use unguarded userdel and groupdel commands which will 
fail when the 
ganglia user and group are not defined locally in the /etc/passwd and 
/etc/group. See inlined patch
which follows recommendations from debian wiki for managing user accounts.



   * What led up to the situation?

Attempts to purge ganglia-monitor on my system fail as I use ldap for central 
management of user accounts.

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

Attempts at purging ganglia-monitor via `dpkg -P` as well as `apt-get remove 
--purge` fail.

   * What was the outcome of this action?

'''
$ sudo apt-get remove --purge ganglia-monitor
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libapr1 libconfuse-common libconfuse0 libganglia1 python-sysadtoolkit-sb
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  ganglia-monitor*
0 upgraded, 0 newly installed, 1 to remove and 140 not upgraded.
After this operation, 241 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 60324 files and directories currently installed.)
Removing ganglia-monitor (3.6.0-6) ...
Purging configuration files for ganglia-monitor (3.6.0-6) ...
userdel: cannot remove entry 'ganglia' from /etc/passwd
dpkg: error processing package ganglia-monitor (--purge):
 subprocess installed post-removal script returned error exit status 1
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
 ganglia-monitor
E: Sub-process /usr/bin/dpkg returned an error code (1)
'''
 
  * What outcome did you expect instead?

package to be removed with all data and configuration purged.


--PATCH--

Index: a/debian/ganglia-monitor.postinst
===
--- a/debian/ganglia-monitor.postinst
+++ b/debian/ganglia-monitor.postinst
@@ -1,10 +1,7 @@
 #!/bin/sh
 set -e

-if ! getent passwd ganglia >/dev/null; then
-   echo Adding system user: ganglia.
-   useradd -r -c "Ganglia Monitor" -d "/var/lib/ganglia" -s "/bin/false" 
-U ganglia
-fi
+adduser --system --gecos "Ganglia Monitor" --home "/var/lib/ganglia" --shell 
"/bin/false" --group ganglia

 #if we have an old 2.5.x gmond
 if [ -f /etc/gmond.conf ]; then
Index: a/debian/ganglia-monitor.postrm
===
--- a/debian/ganglia-monitor.postrm
+++ b/debian/ganglia-monitor.postrm
@@ -2,17 +2,16 @@

 if [ "$1" = "purge" ] ; then
# rm the rrds if this is the last ganglia package being removed.
+   # Only remove ganglia user if gmetad isn't installed
if [ ! -f /usr/sbin/gmetad ] ; then
 if [ -d /var/lib/ganglia ]; then
# Remove rrd dir
rm -rf /var/lib/ganglia/rrds
 fi
-   # Only remove ganglia user if gmetad isn't installed
-if getent passwd ganglia >/dev/null; then
-userdel ganglia
-fi
-if getent group ganglia >/dev/null; then
-groupdel ganglia
+if [ -x "$(command -v deluser)" ]; then
+deluser --quiet --system ganglia > /dev/null || true
+else
+echo >&2 "not removing ganglia system account because deluser 
command was not found"
 fi
 fi
 fi

--END PATCH--


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
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 ganglia-monitor depends on:
ii  adduser  3.113+nmu3
ii  libapr1  1.5.1-3
ii  libc62.19-18
ii  libconfuse0  2.7-5
ii  libexpat12.1.0-6+b3
ii  libganglia1  3.6.0-6
ii  libpcre3 2:8.35-3.3
ii  zlib1g   1:1.2.8.dfsg-2+b1

ganglia-monitor recommends no packages.

ganglia-monitor suggests no packages.

-- no debconf information

Bug#806595: aptitude: now it crashes

[Manuel A. Fernandez Montecelo]

Control: notfound -1 aptitude/0.7.6-1
Control: close -1


2016-02-22 22:07 To Yuri D'Elia:

Control: reopen -1


2016-02-22 19:42 Yuri D'Elia:

Architecture: i386 (i686)


If it can help, on amd64 it works nicely, but I just had the same crash
on i386.


So if somebody can test in non-amd64 arches [1] with this version in
unstable and get a backtrace with gdb or valgrind it would be great.


[1] also working completely fine here, in my usual amd64 machine


Actually, the crash is probably not related to the original problem
reported in #806595, so it'll be better to submit a new bug report
instead of carrying the (likely unrelated) information around.

So Jason, could you please report this as a new bug instead (same as you
did, but sending the bug to "sub...@bugs.debian.org" instead of
"806...@bugs.debian.org"), and ideally with the backtrace?  If you need
help please tell.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#815409: libguestfs: FTBFS on mips: segfault while creating blank-disk-1s.qcow2

[Hilko Bengen]

Control: reassign -1 qemu
Control: retitle -1 qemu-img create -f qcow2 ... segfaults on mips

* Richard W.M. Jones:

> I actually have libguestfs running on mipsel at home.  It's very slow
> indeed :-(

The problem occurs only on mips, not on mipsel. This may be an endianess
problem, I'm going to have a closer look.

> Anyway, it looks as if the segfault is happening in the `qemu-img'
> utility.  The command which fails is:
>
>   qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512
>
> (You could just run that command on its own on the same hardware to
> see if you can reproduce it).

I can reproduce it on one of Debian's mips porterboxes. It happens when
generating qcow2 images, apparently regardless of size and options.

> This bug should probably be reassigned to qemu.

I agree.

Cheers,
-Hilko

Bug#815614: freerdp: Fails to build on non-Linux archs

[Moritz Muehlenhoff]

Source: freerdp
Version: 1.1.0~git20140921.1.440916e+dfsg1-6
Severity: important

Hi,
1.1.0~git20140921.1.440916e+dfsg1-6 and later fail to build on
kfreebsd and hurd since they build-depend on libusb-1.0 and libudev
which are only available on Linux.

If you want to continue to support freerdp on kfreebsd and hurd, you
should limit the build dependencies to linux-any.

Cheers,
Moritz

Bug#815613: wheezy-pu: package clamav/0.99+dfsg-0+deb7u2

[Sebastian Andrzej Siewior]

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

In order to address the Sparc fallout in the Wheezy update (#814544),
here is the fix. This patch is also part of last unstable upload
(0.99+dfsg-2) and pending for Jessie (0.99+dfsg-0+deb8u2, #815598).

Sebastian
diff -Nru clamav-0.99+dfsg/debian/changelog clamav-0.99+dfsg/debian/changelog
--- clamav-0.99+dfsg/debian/changelog   2016-02-18 04:02:24.0 +0100
+++ clamav-0.99+dfsg/debian/changelog   2016-02-22 23:06:12.0 +0100
@@ -1,3 +1,10 @@
+clamav (0.99+dfsg-0+deb7u2) oldstable; urgency=medium
+
+  * Add libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch to get the
+testsuite passed on sparc. It also seem avoid invalid loads on ARMv5 cpus.
+
+ -- Sebastian Andrzej Siewior   Mon, 22 Feb 2016 
23:05:03 +0100
+
 clamav (0.99+dfsg-0+deb7u1) oldstable; urgency=medium
 
   [ Andreas Cadhalpun ]
diff -Nru clamav-0.99+dfsg/debian/.git-dpm clamav-0.99+dfsg/debian/.git-dpm
--- clamav-0.99+dfsg/debian/.git-dpm2016-02-12 20:46:38.0 +0100
+++ clamav-0.99+dfsg/debian/.git-dpm2016-02-22 23:06:12.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-94ee2eaadaedd8160a123737fa554be6acb8b761
-94ee2eaadaedd8160a123737fa554be6acb8b761
+b470f97a68f64348adbd019ffcbff49fe155454f
+b470f97a68f64348adbd019ffcbff49fe155454f
 30b6c6f47c6648ee0ba78a71d4664f5917d83bcb
 30b6c6f47c6648ee0ba78a71d4664f5917d83bcb
 clamav_0.99+dfsg.orig.tar.xz
diff -Nru 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
--- 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
  1970-01-01 01:00:00.0 +0100
+++ 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
  2016-02-22 23:06:12.0 +0100
@@ -0,0 +1,94 @@
+From b470f97a68f64348adbd019ffcbff49fe155454f Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior 
+Date: Sat, 20 Feb 2016 15:53:48 +0100
+Subject: libclamav: yara: avoid unaliged access to 64bit variable
+
+The derefence of an unaligned 64bit variable results in a SIGBUS abort
+on 32bit SPARC. ARMv5 CPUs seem to perform the load but load garbish.
+This memcpy() workaround forces the compiler to do something that works
+on even if the data was not properly aligned. For X86 it means no
+change. ARM on other hand will produce slightly different code depending
+on the CPU used.
+
+Patch-Name: libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ libclamav/yara_exec.c | 18 +-
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/libclamav/yara_exec.c b/libclamav/yara_exec.c
+index dbd7ae8..808a030 100644
+--- a/libclamav/yara_exec.c
 b/libclamav/yara_exec.c
+@@ -184,7 +184,7 @@ int yr_execute_code(
+ #endif
+ 
+   case OP_PUSH:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(r1);
+ break;
+@@ -194,38 +194,38 @@ int yr_execute_code(
+ break;
+ 
+   case OP_CLEAR_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1] = 0;
+ break;
+ 
+   case OP_ADD_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ mem[r1] += r2;
+ break;
+ 
+   case OP_INCR_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1]++;
+ break;
+ 
+   case OP_PUSH_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(mem[r1]);
+ break;
+ 
+   case OP_POP_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(mem[r1]);
+ break;
+ 
+   case OP_SWAPUNDEF:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ if (r2 != UNDEFINED)
+@@ -540,7 +540,7 @@ int yr_execute_code(
+ 
+ // r1 = number of arguments
+ 
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ // pop arguments from stack and copy them to args array
+@@ -854,7 +854,7 @@ int yr_execute_code(
+ 
+ #if REAL_YARA //not supported ClamAV
+   case OP_IMPORT:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ FAIL_ON_ERROR(yr_modules_load(

Bug#815612: libgdk-pixbuf2.0-0: JPEG2000 support is missing

[Dima Kogan]

Package: libgdk-pixbuf2.0-0
Severity: normal
Hi. In August 2015 JPEG2000 support was removed:

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

The cited rationale was the poor state of the library providing this
support. I have no particular love of jasper, but supporting JPEG2000 is
desirable. It is indeed somewhat "exotic" and "fringe", and you usually
don't need it; until you do.

What needs to happen to get this support back in some way?

Thanks.


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, armel, i386

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

Bug#806595: aptitude: now it crashes

[Manuel A. Fernandez Montecelo]

Control: reopen -1


2016-02-22 19:42 Yuri D'Elia:

Architecture: i386 (i686)


If it can help, on amd64 it works nicely, but I just had the same crash
on i386.


So if somebody can test in non-amd64 arches [1] with this version in
unstable and get a backtrace with gdb or valgrind it would be great.


[1] also working completely fine here, in my usual amd64 machine

--
Manuel A. Fernandez Montecelo 

Bug#815555: initramfs-tools: raid1 boot with lilo fails on 0.123 with cant find root in fstab

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2016-02-22 at 12:58 +0100, Anders Nyvang wrote:
> Package: initramfs-tools
> Version: 0.123
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> After updating from 0.120 to 0.123 my system cannot boot.
> 
> System is software raid1 and booting with lilo.
> 
> Post up to the initramfs prompt:
> BIOS data check successful
> mdadm: /dev/md0 has been started with 2 drives.
> modprobe: module unknown not found in modules.dep
> mount: can't find /root in /etc/fstab
> 
> ... and the errors goes on, but primary relates to the fact that the root 
> filesystem is missing.
[...]

What filesystem type is the root mounted with, when you use
initramfs-tools 0.120?  (Check in /proc/mounts.)

What does '/usr/lib/klibc/bin/fstype /dev/md0' show?

What does 'blkid /dev/md0' show?

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou

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

Bug#815598: jessie-pu: package clamav/0.99+dfsg-0+deb8u2

[Sebastian Andrzej Siewior]

On 2016-02-22 21:43:45 [+], Adam D. Barratt wrote:
> Please go ahead.
Thanks, done.

> Regards,
> 
> Adam

Sebastian

Bug#807274: wheezy-pu: package ca-certificates/20130119+deb7u2

[Michael Shuler]

On 02/20/2016 06:53 AM, Adam D. Barratt wrote:
> For reference, neither the above nor the message opening the bug made it
> to debian-release, presumably for size reasons.

Thanks for the follow up.

> Looking at the diff:
> 
> diff -Nru ca-certificates-20130119+deb7u1/debian/config 
> ca-certificates-20130119+deb7u2/debian/config
> --- ca-certificates-20130119+deb7u1/debian/config 2014-09-24 
> 12:57:57.0 -0500
> +++ ca-certificates-20130119+deb7u2/debian/config 1969-12-31 
> 18:00:00.0 -0600
> 
> I'm assuming that wasn't intentional?

This is the unintentional result of building from a clean git checkout.
I'll have to pull the old generated debian/config from the existing
source package. This file has since been added to the clean target.

This Wheezy package is going to suffer from the same regression as in
Jessie, currently. Please, leave this bug report in "moreinfo", if
that's OK, or just close this and I'll open a new report. I will need to
create an updated diff that includes the removed 1024-bit CA
certificates, once I'm sure that's working correctly in Jessie.

-- 
Kind regards,
Michael

Bug#815581: [Aptitude-devel] Bug#815581: aptitude crashes when trying to show information about packages that are not installed

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2016-02-22 18:02 Axel Beckert:

Control: tag -1 + confirmed
Control: severity serious

Hi,

nkiesel wrote:

I just upgraded to the latest aptitude and I get a core dump when running
`aptitude show elpa-projectile` (which is a new package I don't have
installed).  `aptitude show aptitude` works.


thanks for that bug report. I can confirm this issue on amd64.


Fixed now, marking as +pending, thanks.


--
Manuel A. Fernandez Montecelo 

Bug#815241: xul-ext-mozvoikko: Iceweasel crashes at startup if xul-ext-mozvoikko is installed

[Antti Jarvinen]

Indeed, libvoikko got upgraded to 4.something and the problem
disappeared. So this bug report can be closed. 

--
Antti

Bug#781369: Invalid field given (Files_Excluded)

[gregor herrmann]

Control: tag -1 + confirmed
Control: reassign -1 libdebian-copyright-perl
Control: affects -1 license-reconcile
Control: forcemerge 738481 -1

On Sat, 28 Mar 2015 08:57:28 +0100, Picca Frédéric-Emmanuel wrote:

> Package: license-reconcile
> Version: 0.5
> Severity: normal
> 
> Debian/main/spyder/spyder$ license-reconcile
> CopyrightParsing: Invalid field given (Files_Excluded) at 
> /usr/share/perl5/Debian/Copyright.pm line 123.

This is #738481 in libdebian-copyright-perl.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bob Dylan: If You Ever Go To Houston


signature.asc
Description: Digital Signature

Bug#815601: gnugo: please make the build reproducible

[Reiner Herrmann]

Source: gnugo
Version: 3.8-8
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that gnugo could not be built reproducibly.
The md5sums file generated during build varies with the readdir order.

The attached patch fixes this by sorting the output from find.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/rules b/debian/rules
index 33d07ad..dac2c30 100755
--- a/debian/rules
+++ b/debian/rules
@@ -73,7 +73,7 @@ endif
 
 	install -d -p -m 0755 debian/gnugo/DEBIAN
 	install-p -m 0755 debian/postinst debian/postrm debian/gnugo/DEBIAN
-	cd debian/gnugo && find usr -type f -print0 | xargs -0 md5sum > DEBIAN/md5sums
+	cd debian/gnugo && find usr -type f -print0 | LC_ALL=C sort -z | xargs -0 md5sum > DEBIAN/md5sums
 	cd debian/gnugo && find etc -type f | sed 's@^@/@' > DEBIAN/conffiles
 
 	chmod -R u+w,go=u-w debian/gnugo


signature.asc
Description: PGP signature

Bug#815602: xserver-xorg-core: cannot start second session on different display if one is already running

[Giuseppe Bilotta]

Package: xserver-xorg-core
Version: 2:1.18.1-1
Severity: normal

I normally boot in console (text mode w/ KMS) and start X manually.
Today I discovered that I cannot start a second X session while the
first one is running.

Steps to reproduce:

1. boot to console (not X);
2. login;
3. start X (e.g. with `xinit`);
4. switch to a different VT (ctrl+alt+f2);
5. login as the same user;
6. start X again on a different disply (e.g. with: `xinit -- :1`);

the second session fails to start. The error is something like:

[ 15201.424] (EE) 
Fatal server error:
[ 15201.424] (EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or 
directory)
[ 15201.424] (EE) 
[ 15201.424] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[ 15201.424] (EE) Please also check the log file at 
"/home/oblomov/.local/share/xorg/Xorg.1.log" for additional information.
[ 15201.424] (EE) 


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

lrwxrwxrwx 1 root root 13 Aug  9  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Feb  9 12:12 /usr/bin/Xorg

Diversions concerning libGL are in place

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

Bug#815497: crosshurd: Hurd deb package fails to install

[raphael truc]

Hi,

It's totally up to date
In fact, I tried on another box, just using a temporary folder, and it
worked without problems, maybe I have a glitch in my shell environnement...

2016-02-22 22:16 GMT+01:00 Samuel Thibault :

> raphael truc, on Mon 22 Feb 2016 22:13:50 +0100, wrote:
> > It's a stretch host
>
> Ok, same here. I guess it's completely up to date?
>
> > Maybe there is a conf file somewhere I missed !
>
> The default values provided in /etc/crosshurd should just work fine, and
> what is not there is asked interactively by crosshurd.
>
> Samuel
>

Bug#815600: isympy: lacks a dependency on python-sympy | python3-sympy

[Francesco Poli (wintermute)]

Package: isympy
Version: 0.7.6.1-1
Severity: grave
Justification: renders package unusable

Hello and thanks for maintaining the sympy Debian package!

I think binary isympy lacks a dependency on python-sympy | python3-sympy.
Without this dependency, installing it leaves the package in an unusable
state:

  $ su -
  Password:
  # aptitude install isympy
  The following NEW packages will be installed:
ipython{a} isympy python-decorator{a} python-pexpect{a} 
python-ptyprocess{a} python-simplegeneric{a}
  [...]
  Setting up isympy (0.7.6.1-1) ...

  # exit
  $ isympy 
  Traceback (most recent call last):
File "/usr/bin/isympy", line 357, in 
  main()
File "/usr/bin/isympy", line 353, in main
  from sympy.interactive import init_session
  ImportError: No module named sympy.interactive
  $ su -
  Password:
  # aptitude install python-sympy
  The following NEW packages will be installed:
dvipng{a} python-gmpy{a} python-mpmath{a} python-pyglet{a} python-sympy
python-sympy-doc{a}
  [...]
  Setting up python-sympy-doc (0.7.6.1-1) ...
  Processing triggers for menu (2.1.47) ...

  # exit
  $ isympy 
  IPython console for SymPy 0.7.6.1 (Python 2.7.11-64-bit) (ground types: gmpy)

  These commands were executed:
  >>> from __future__ import division
  >>> from sympy import *
  >>> x, y, z, t = symbols('x y z t')
  >>> k, m, n = symbols('k m n', integer=True)
  >>> f, g, h = symbols('f g h', cls=Function)
  >>> init_printing()

  Documentation can be found at http://www.sympy.org

  In [1]:


Hence, isympy should depend on python-sympy | python3-sympy.
Please add this dependency.

Thanks for your time!
Bye.



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

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

Versions of packages isympy depends on:
pn  python:any | python:any  

Versions of packages isympy recommends:
ii  ipython  2.4.1-1

isympy suggests no packages.

-- no debconf information

Bug#815598: jessie-pu: package clamav/0.99+dfsg-0+deb8u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2016-02-22 at 22:09 +0100, Sebastian Andrzej Siewior wrote:
> In order to address the Sparc fallout in the Wheezy update (#814544), here
> is the fix for Jessie. This patch is also part of last unstable upload
> (0.99+dfsg-2).

Please go ahead.

Regards,

Adam

Bug#815183: aptitude: [INTL:nl] Dutch po file for the aptitude package's documentation

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Frans,

2016-02-19 20:04 Frans Spiesschaert:


Dear Maintainer,

Please find attached the Dutch po file for the aptitude package's
documentation. It has been submitted for review to the
debian-l10n-dutch mailing list. Please add it to your next package
revision. It should be put as "doc/po4a/po/nl.po" in your package build tree.


Applied, thanks.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#815185: aptitude: [INTL:nl] Dutch po file for the aptitude package

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


2016-02-19 20:08 Frans Spiesschaert:

Dear Maintainer,

Please find attached the updated Dutch po file for the aptitude package.
It has been submitted for review to the debian-l10n-dutch mailing list.
Please add it to your next package revision.
It should be put as "po/nl.po" in your package build tree.


Applied, thanks.


--
Manuel A. Fernandez Montecelo 

Bug#815576: Pending fixes for bugs in the libany-uri-escape-perl package

[pkg-perl-maintainers]

tag 815576 + pending
thanks

Some bugs in the libany-uri-escape-perl package are closed in
revision 822aa424eb83b0b6cbb40bb95bd0683bfa2bc086 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libany-uri-escape-perl.git/commit/?id=822aa42

Commit message:

Add liburi-escape-xs-perl to Recommends

since the very purpose of using Any::URI::Escape is to weak-requiring
URI::Escape::XS.

Also make sure it's installed at build time.

Thanks: Jonas Smedegaard for the bug report.
Closes: #815576

Bug#815576: liburi-escape-xs-perl: should explicitly recommend liburi-escape-xs-perl (not only fallback-depend on it)

[Jonas Smedegaard]

Quoting gregor herrmann (2016-02-22 21:35:56)
> On Mon, 22 Feb 2016 21:18:02 +0100, Jonas Smedegaard wrote:
> 
> > > Should this be "Control: reassign -1 libany-uri-escape-perl"?
> > Whoops - yeah.  
> 
> Ok, thanks.
> 
> > Should be done now (using bcc to control@b.d.o - would 
> > above syntax work without bcc?).
> 
> Yup, Control: pseudo-headers in mails to nn@b.d.o work as well.

Nice.  Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#812251: fixed in apt 1.2.1

[Francesco Poli]

On Mon, 22 Feb 2016 21:24:04 +0100 David Kalnischkies wrote:

> On Mon, Feb 22, 2016 at 03:21:14PM +0100, Marc Haber wrote:
> > On Sun, Feb 21, 2016 at 11:11:57PM +0100, David Kalnischkies wrote:
> > > Zip up the lists/ directory + your /etc/apt. DO NOT run update again
> > > before doing that. Upload that somewhere.
> > 
> > http://q.bofh.de/~mh/stuff/apt-data-812251.tar.xz (42MB)
> > 
> > Hope this helps. Please tell me when I can remove the download
> 
> Thanks (also to Francesco who uploaded the files privately).

You're welcome!

> 
> Unfortunately I can't reproduce it with either at the moment, which is
> a bit strange at the very least in Francesco's case as his output
> suggests a segfault at 65% done, which should be still inside the lists/
> files and not in the dpkg/status file as the later is very small
> compared to (multiple) Packages+Translation files. Mh.
> 
> I drop my binary caches just to be sure
> # rm /var/cache/apt/*.bin
> and then I am trying as user with
> $ apt-cache policy -o dir::etc=/tmp/poli/etc -o 
> dir::state::lists=/tmp/poli/lists -o apt::architecture=i386
> 
[...]
> That should be segfaulting as any apt command is building a binary cache
> (if need be in memory only), but it doesn't for me. I presume it does
> for you guys…

The above commands lead to a segfault on my i386 Debian testing box
(Soekris net5501-60 board), but not on an amd64 box.

Have you tried to reproduce the bug on an i386 (real hardware or
virtual) machine?



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


pgpbJpKQTWw6w.pgp
Description: PGP signature

Bug#815554: [Aptitude-devel] Bug#815554: aptitude: truncated hostname in header line (regression)

[Manuel A. Fernandez Montecelo]

Hi,

2016-02-22 17:14 Axel Beckert:

Control: tag -1 + confirmed

Hi,

Vincent Lefevre wrote:

When I run aptitude, I get the following header line:

aptitude 0.7.6 @ cven

on my machine cventin, i.e. the hostname is truncated.


Indeed.

This seems to depend on the terminal width. The amount of characters
of the hostname shown changes when I resize the terminal, aptitude
runs in.


I had to do some changes to the size due to #810221 -- the fields Broken
and Download size are more important than host for most people, I guess.

Some people like the hostname being there, but I am still wondering if
it was an error to honour that request and enable it by default, because
we have had 2 reports because of it in a short time.

Due to the rules of creating columns in aptitude/cwidget, this is a bit
of a mess (it needs to reserve space beforehand even if the line appears
empty).  In any case, something has to give, and it's impossible to
support largish hostnames in 80-width characters anyway.

I haven't tried, but this should be able to be worked around by setting
Aptitude::UI::Package-Header-Format, and establishing a given width for
the hostname field.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#815599: mariadb-server-10.0: Postinstall script does not clear the mysql-server/root_password_again field

[Owen, Brynnen]

Package: mariadb-server-10.0
Version: 10.0.23-0+deb8u1
Severity: minor

Dear Maintainer,

While looking to preseed some Jessie systems, I noticed that the 
mysql-server/root_password field had been cleared in the postinstall script, 
however the mysql-server/root_password_again field had not been. Therefore, the 
root password for the database, if not reset after installation, was available 
in cleartext from debconf.

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

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

Versions of packages mariadb-server-10.0 depends on:
ii  adduser   3.113+nmu3
ii  debconf [debconf-2.0] 1.5.56
ii  libaio1   0.3.110-1
ii  libc6 2.19-18+deb8u3
ii  libdbi-perl   1.631-3+b1
ii  libpam0g  1.1.8-3.1+deb8u1
ii  libstdc++64.9.2-10
ii  lsb-base  4.1+Debian13+nmu1
ii  mariadb-client-10.0   10.0.23-0+deb8u1
ii  mariadb-common10.0.23-0+deb8u1
ii  mariadb-server-core-10.0  10.0.23-0+deb8u1
ii  passwd1:4.2-3+deb8u1
ii  perl  5.20.2-3+deb8u3
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages mariadb-server-10.0 recommends:
ii  libhtml-template-perl  2.95-1

Versions of packages mariadb-server-10.0 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-2
pn  mariadb-test   
pn  tinyca 

-- debconf information:
* mysql-server/root_password_again: (password omitted)
* mysql-server/root_password: (password omitted)
  mariadb-server/oneway_migration: true
  mysql-server/password_mismatch:
  mysql-server/no_upgrade_when_using_ndb:
  mysql-server-10.0/postrm_remove_databases: false
  mysql-server-10.0/nis_warning:
  mariadb-server-10.0/really_downgrade: false
  mysql-server/error_setting_password:

Bug#807074: closed by jac...@debian.org (Eugene V. Lyubimkin) (Bug#807074: fixed in fbreader 0.12.10dfsg2-1)

[Francesco Poli]

On Sun, 21 Feb 2016 10:21:20 + Debian Bug Tracking System wrote:

[...]
>* debian/dfsg-repack:
>  - Also remove docbook- and XHTML entity files. (Closes: #807074)
[...]

Hello Eugene,
thanks for dealing with this bug.

I noticed that
https://tracker.debian.org/media/packages/f/fbreader/copyright-0.12.10dfsg2-1
still mentions the *.ent files and their problematic license.

Please update the debian/copyright file so that it reflects the
current licensing status of the package.


On the other hand, I suppose that the files in distributions/debian
are unused (some distributions/debian/*/copyright files also refer
to the problematic ISO license...).

Please let me know.
Thanks for your time!


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


pgpBp9y2RU1qu.pgp
Description: PGP signature

Bug#815503: dbus-x11: Several session buses if scripts in Xsession.d use D-Bus

[Simon McVittie]

On Mon, 22 Feb 2016 at 21:18:13 +0100, Samuel Thibault wrote:
> Simon McVittie, on Mon 22 Feb 2016 07:18:28 +, wrote:
> > Since dbus 1.10 (in stretch), we have mitigated this differently, by
> > running dbus-launch from 75dbus_dbus-launch as you suggest,
> 
> ? No, it is still prepended to $STARTUP only.

My mistake; it's started early if you have the dbus-user-session package
(dbus started by systemd --user) but not if you're relying on dbus-launch.

Nobody has reported major issues with dbus-user-session so far, so I
think we could extend this model to the dbus-launch code path in stretch.
I still think this is too disruptive a change to be suitable for stable,
though.

S

Bug#722017: xfonts-terminus: iso10646 font is unusable with xterm

[Robbie Harwood]

Package: xfonts-terminus
Version: 4.39-1
Followup-For: Bug #722017

Dear Maintainer,

This issue also manifests in other programs, such as xmobar and dzen2 (and GUI
emacs, if you believe stack overflow).  I noticed this issue on upgrade from
stable, where it was previously working.

Please fix this.  It makes Terminus very difficult to use in UTF-8
environments when every chareacter gets replaced with 'n'.

Thanks!

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

Kernel: Linux 4.3.0-1-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: sysvinit (via /sbin/init)

Versions of packages xfonts-terminus depends on:
ii  xfonts-utils  1:7.7+3

xfonts-terminus recommends no packages.

Versions of packages xfonts-terminus suggests:
ii  tightvncserver [xserver]  1.3.9-7
ii  xfonts-terminus-oblique   4.39-1
ii  xserver-xorg [xserver]1:7.7+13

-- no debconf information

Bug#815512: Forgot patch

[Reiner Herrmann]

Sorry, I forgot to attach the patch in report. :)
diff --git a/debian/rules b/debian/rules
index 154ec5e..54c03dc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -174,9 +174,9 @@ ifneq (,$(findstring -a, $(DH_OPTIONS)))
 	DH_OPTIONS= dh_strip -psip-dev --dbg-package=sip-dbg
 endif
 	dh_compress -X.inv
-	dh_fixperms
 	dh_python2 --no-dbg-cleaning -N sip-dev
 	dh_python3 --no-dbg-cleaning -N sip-dev
+	dh_fixperms
 	dh_installdeb
 	dh_shlibdeps
 	dh_gencontrol


signature.asc
Description: PGP signature

Bug#815497: crosshurd: Hurd deb package fails to install

[Samuel Thibault]

raphael truc, on Mon 22 Feb 2016 22:13:50 +0100, wrote:
> It's a stretch host

Ok, same here. I guess it's completely up to date?

> Maybe there is a conf file somewhere I missed !

The default values provided in /etc/crosshurd should just work fine, and
what is not there is asked interactively by crosshurd.

Samuel

Bug#815544: aptitude using %e as display-format code leads to error without output always

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Christoph,

2016-02-22 09:45 Christoph Maser:

Package: aptitude
Version: 0.6.11-1+b1
Severity: important
 
 
Dear Maintainer,
when using the escape code "%e" in aptitude --display-format (-F) it will 
always return an empty result. (%O seems to fail too)


If the version reported above is the correct one (please confirm), that
version doesn't accept neither %e nor %O (only some in the series 0.7.x
do).

Additionally, only 0.7.6 will tell you when you are using escapes which
are unsupported (bug #813319).


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#815497: crosshurd: Hurd deb package fails to install

[raphael truc]

It's a stretch host
Maybe there is a conf file somewhere I missed !

2016-02-22 19:58 GMT+01:00 Samuel Thibault :

> raphael truc, on Mon 22 Feb 2016 19:50:49 +0100, wrote:
> > Well, I mount the partition on /mnt and run crosshurd
>
> Well, that works for me :)
>
> Are you using a jessie, stretch or sid host?
>
> Samuel
>

Bug#815598: jessie-pu: package clamav/0.99+dfsg-0+deb8u2

[Sebastian Andrzej Siewior]

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

In order to address the Sparc fallout in the Wheezy update (#814544), here
is the fix for Jessie. This patch is also part of last unstable upload
(0.99+dfsg-2).

Sebastian
diff -Nru clamav-0.99+dfsg/debian/changelog clamav-0.99+dfsg/debian/changelog
--- clamav-0.99+dfsg/debian/changelog   2015-12-14 21:44:42.0 +0100
+++ clamav-0.99+dfsg/debian/changelog   2016-02-22 21:15:44.0 +0100
@@ -1,3 +1,10 @@
+clamav (0.99+dfsg-0+deb8u2) stable; urgency=medium
+
+  * Add libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch to get the
+testsuite passed on sparc. It also seem avoid invalid loads on ARMv5 cpus.
+
+ -- Sebastian Andrzej Siewior   Mon, 22 Feb 2016 
21:12:51 +0100
+
 clamav (0.99+dfsg-0+deb8u1) stable; urgency=medium
 
   [ Andreas Cadhalpun ]
diff -Nru clamav-0.99+dfsg/debian/.git-dpm clamav-0.99+dfsg/debian/.git-dpm
--- clamav-0.99+dfsg/debian/.git-dpm2015-12-11 21:20:24.0 +0100
+++ clamav-0.99+dfsg/debian/.git-dpm2016-02-22 21:15:44.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-1cc3015d9abdb6a121251aab899dc1baf3117baf
-1cc3015d9abdb6a121251aab899dc1baf3117baf
+bbc0790fa239ec754ca1693244acacd2e55f97b5
+bbc0790fa239ec754ca1693244acacd2e55f97b5
 30b6c6f47c6648ee0ba78a71d4664f5917d83bcb
 30b6c6f47c6648ee0ba78a71d4664f5917d83bcb
 clamav_0.99+dfsg.orig.tar.xz
diff -Nru 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
--- 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
  1970-01-01 01:00:00.0 +0100
+++ 
clamav-0.99+dfsg/debian/patches/libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
  2016-02-22 21:15:44.0 +0100
@@ -0,0 +1,94 @@
+From bbc0790fa239ec754ca1693244acacd2e55f97b5 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior 
+Date: Sat, 20 Feb 2016 15:53:48 +0100
+Subject: libclamav: yara: avoid unaliged access to 64bit variable
+
+The derefence of an unaligned 64bit variable results in a SIGBUS abort
+on 32bit SPARC. ARMv5 CPUs seem to perform the load but load garbish.
+This memcpy() workaround forces the compiler to do something that works
+on even if the data was not properly aligned. For X86 it means no
+change. ARM on other hand will produce slightly different code depending
+on the CPU used.
+
+Patch-Name: libclamav-yara-avoid-unaliged-access-to-64bit-variab.patch
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ libclamav/yara_exec.c | 18 +-
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/libclamav/yara_exec.c b/libclamav/yara_exec.c
+index dbd7ae8..808a030 100644
+--- a/libclamav/yara_exec.c
 b/libclamav/yara_exec.c
+@@ -184,7 +184,7 @@ int yr_execute_code(
+ #endif
+ 
+   case OP_PUSH:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(r1);
+ break;
+@@ -194,38 +194,38 @@ int yr_execute_code(
+ break;
+ 
+   case OP_CLEAR_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1] = 0;
+ break;
+ 
+   case OP_ADD_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ mem[r1] += r2;
+ break;
+ 
+   case OP_INCR_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ mem[r1]++;
+ break;
+ 
+   case OP_PUSH_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ push(mem[r1]);
+ break;
+ 
+   case OP_POP_M:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(mem[r1]);
+ break;
+ 
+   case OP_SWAPUNDEF:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ pop(r2);
+ if (r2 != UNDEFINED)
+@@ -540,7 +540,7 @@ int yr_execute_code(
+ 
+ // r1 = number of arguments
+ 
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ // pop arguments from stack and copy them to args array
+@@ -854,7 +854,7 @@ int yr_execute_code(
+ 
+ #if REAL_YARA //not supported ClamAV
+   case OP_IMPORT:
+-r1 = *(uint64_t*)(ip + 1);
++memcpy(, ip + 1, sizeof(uint64_t));
+ ip += sizeof(uint64_t);
+ 
+ FAIL_ON_ERROR(yr_modules_load(
diff -Nru clamav-0.99+dfsg/debian/patches/series 

Bug#814951: bug#13414: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951: libassuan: add libassuan-mingw-w64-dev for cross-building to Windows targets

[Peter Rosin]

On 2016-02-22 12:44, Pavel Raiskup wrote:
> Hi Daniel,
> 
> On Saturday 20 of February 2016 14:29:47 Daniel Kahn Gillmor wrote:
>> Over on https://bugs.debian.org/814951, Werner Koch and i are discussing
>> how https://debbugs.gnu.org/13414 is still a problem with libtool.  In
>> particular, GNU libtool can't seem to detect that a .def file is valid
>> unless EXPORT is the literal first line in the file (it chokes when
>> blank lines or comments precede EXPORT).
>>
>> Werner supplied the patch below to fix libtool.  The upstream bug
>> appears to have a rather different set of patches.  Either way, the
>> problem should be cleaned up in libtool, as it's causing a series of
>> workarounds for cross-building things on debian for the Windows
>> platform.
>>
>> Is there some reason for the delay upstream besides lack of time to work
>> on it?  Should debian go ahead and apply one of the proposed patches
>> downstream in the meantime?
> 
> From the patch itself:
> 
> There is no need to send this upstream.  Upstream's git master has a
> lot of changes including a similar fix for this problems.  There are
> no signs that a libtool 2.4.3 will be released to fix this problem and
> thus we need to stick to our copy of 2.4.2 along with this patch.
> 
> It is quite some time libtool 2.4.3 was released, the latest release is 2.4.6
> now.  Can you check that update helps?

Hi!

The libtool patch from https://debbugs.gnu.org/13414 is better than the
debian patch from https://bugs.debian.org/814951 in every aspect that I
can see and should indeed help.

For reference, the libtool patch was committed here
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=a5a4944fbb2bbd

(three years old, released one year ago in 2.4.3)

Cheers,
Peter

Bug#815576: liburi-escape-xs-perl: should explicitly recommend liburi-escape-xs-perl (not only fallback-depend on it)

[gregor herrmann]

On Mon, 22 Feb 2016 21:18:02 +0100, Jonas Smedegaard wrote:

> > Should this be "Control: reassign -1 libany-uri-escape-perl"?
> Whoops - yeah.  

Ok, thanks.

> Should be done now (using bcc to control@b.d.o - would 
> above syntax work without bcc?).

Yup, Control: pseudo-headers in mails to nn@b.d.o work as well.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Funny Van Dannen: Luftballon


signature.asc
Description: Digital Signature

Bug#815328: python-llfuse: FTBFS on kfreebsd: unsatisfiable B-D: fuse

[Steven Chamberlain]

Nikolaus Rath wrote:
> Ah, ok. I guess it gives non-zero exact status if it doesn't find any
> tests to run at all.
> 
> So the next question is why is it finding only one test, and why is it
> skipping that one.
> 
> * Is there a "fusermount" executable available on kfreebsd?

No, but there is a mount_fusefs in package fuse4bsd.

Also I realised when I suggested before putting in Build-Depends:
fuse [linux-any] | fuse4bsd [kfreebsd-any],
that actually does not do as intended unless written as:
fuse [linux-any], fuse4bsd [kfreebsd-any],

> * Can you re-run with 'py.test-3 --collect-only test/'?

I tried on two different machines with the same result:
 1. a restricted chroot like on the buildds, clean up-to-date sid,
without the fuse kernel module loaded, and no /dev/fuse;
 2. a local machine having the kernel module loaded, and /dev/fuse.

$ py.test-3 --collect-only test/ ; echo exit status $?
= test session starts ==
platform gnukfreebsd10 -- Python 3.4.4rc1, pytest-2.8.5, py-1.4.31, 
pluggy-0.3.1 -- /usr/bin/python3
cachedir: test/.cache
rootdir: /home/steven/python-llfuse-0.41.1+dfsg/test, inifile: pytest.ini
collected 0 items / 1 skipped 

== 1 skipped in 0.06 seconds ===
exit status 5

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#780721: iputils: Please raise libcap2-bin from Recommends to Depends

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/22/2016 09:22 PM, Noah Meyerhans wrote:
> On Mon, Feb 22, 2016 at 09:15:37PM +0100, John Paul Adrian Glaubitz
> wrote:
>> I didn't say you should remove setuid altogether. I just said you
>> should use capabilties on Linux by default by setting:
>> 
>> Depends: libcap2-bin [linux-any]
> 
> Recommends are installed by default, so the default on Linux is to
> use capabilities. Especially with systemd pulling it in as a hard 
> requirement.

As I mentioned before, the problem occurs in setups like FAI where
Recommends are not enabled by default. I'm aware it works on standard,
stand-alone systems. I haven't had the time to re-test this today
at work, but I will be following up on this!

> iputils-ping only builds for linux kernels.

Well, then this part isn't an issue anyway :).

> I already explained that it would be a policy violation for
> iputils-ping to have a Depends: libcap2-bin. This will change when
> libcap2-bin is Priority: important, at which point I'll add the
> dependency. Just because systemd is willing to violate policy
> doesn't mean I am! ;)

Alright, then let's just wait until this has happened!

Again, thanks for filing the bug report!

Adrian

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

iQIcBAEBCAAGBQJWy286AAoJEHQmOzf1tfkTe+MQAIcf5aaQwxtREO4elmSWUxX8
gfbs0KNCDGCde4imv8zxBcjJBhWvheG0aM65WM/RMj7zBazx5ubUcRXPUR1xjVvu
mb7fSr/68P9MbQKAYDn6FUszfycPb47U6PPZmLC9tVp71kbpGe5IQ+cCrtBgG0dx
yu5ydzpDq/Y8DK8qkfDpuIrepF3uWdnlKJ5SkWBffBZOJYahes9/kh0sByxaz4Di
z3cZ2rXAyexb5FcDGcNl1C9HGkS6vUFDD6a3KpARExl0T9Ve6MuvYM1yTQTWG379
F+eANowp6y5Tfi2rqTfR/K+z2x9aKfnJlkB7XEiRSxwssc989ZXK3ZjPq09wWdGk
UdpHZ6OIZi0eZyMV4xkK+3Mv9hfXLkYAUL7zboPIY15NDZWmegNIXAe7CCCn88Ay
J4HZiOZYIRsW16pXVF/F8081/2g+Ru2Od1+G7Rp4jE+Zt8+/qmZPpGys3kqbZdYE
lnw/ulfaxYnMMIgXdCkjc51ShBCGfm0XGI1etMd7j0Ii4FtMoeNSdAReikqn1UJr
OA75zioM2OHyQEYaR83I8TbngVgcwWYMyuzj+qS+yG3o7QLAqmQAnZBaBJbC8uHS
qxo6jZFvBJuzNYKFGNwnVPMXXVZwsfVB65ASH2HHIyoA09hARGz6HSgbtME/3o4Q
JrXaircc4YHctOzaksgT
=B6Ga
-END PGP SIGNATURE-

Bug#815597: liboctave3: add upstream patch for HDF5 regression

[Elvis Stansvik]

Package: liboctave3
Severity: normal
Tags: upstream

Dear Maintainer,

Please consider patching the package with following fix from upstream:

http://savannah.gnu.org/bugs/?45225

It was a regression in 4.0.0, and without the patch (which will be in
4.0.1), Octave is unusable with HDF5 files with integer data.

Best regards,
Elvis Stansvik

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

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

Bug#812251: fixed in apt 1.2.1

[David Kalnischkies]

On Mon, Feb 22, 2016 at 03:21:14PM +0100, Marc Haber wrote:
> On Sun, Feb 21, 2016 at 11:11:57PM +0100, David Kalnischkies wrote:
> > Zip up the lists/ directory + your /etc/apt. DO NOT run update again
> > before doing that. Upload that somewhere.
> 
> http://q.bofh.de/~mh/stuff/apt-data-812251.tar.xz (42MB)
> 
> Hope this helps. Please tell me when I can remove the download

Thanks (also to Francesco who uploaded the files privately).

Unfortunately I can't reproduce it with either at the moment, which is
a bit strange at the very least in Francesco's case as his output
suggests a segfault at 65% done, which should be still inside the lists/
files and not in the dpkg/status file as the later is very small
compared to (multiple) Packages+Translation files. Mh.

I drop my binary caches just to be sure
# rm /var/cache/apt/*.bin
and then I am trying as user with
$ apt-cache policy -o dir::etc=/tmp/poli/etc -o 
dir::state::lists=/tmp/poli/lists -o apt::architecture=i386
and
$ apt-cache policy -o dir::etc=/tmp/haber/etc/apt -o 
dir::state::lists=/tmp/haber/var/lib/apt/lists
respectively.

That should be segfaulting as any apt command is building a binary cache
(if need be in memory only), but it doesn't for me. I presume it does
for you guys…


(Not a hell of a lot of time at the moment, so if someone else feels
like working on it I wouldn't complain)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#780721: iputils: Please raise libcap2-bin from Recommends to Depends

[Noah Meyerhans]

On Mon, Feb 22, 2016 at 09:15:37PM +0100, John Paul Adrian Glaubitz wrote:
> I didn't say you should remove setuid altogether. I just said you should
> use capabilties on Linux by default by setting:
> 
>   Depends: libcap2-bin [linux-any]

Recommends are installed by default, so the default on Linux is to use
capabilities. Especially with systemd pulling it in as a hard
requirement.

> I'm aware we can't use capabilities on the non-Linux kernels yet, but
> since dpkg allows us to set dependencies per arch or per kernel, I don't
> see any particular problem adding libcap2-bin as to Depends for Linux
> kernels.

iputils-ping only builds for linux kernels.

I already explained that it would be a policy violation for iputils-ping
to have a Depends: libcap2-bin. This will change when libcap2-bin is
Priority: important, at which point I'll add the dependency. Just
because systemd is willing to violate policy doesn't mean I am! ;)

noah



signature.asc
Description: Digital signature

Bug#815503: dbus-x11: Several session buses if scripts in Xsession.d use D-Bus

[Samuel Thibault]

Simon McVittie, on Mon 22 Feb 2016 07:18:28 +, wrote:
> On Sun, 21 Feb 2016 at 23:50:09 +0100, Samuel Thibault wrote:
> > We have been noticing several dbus-daemon --session being started during
> > a user session, which creates a mess, notably with accessibility
> > engines.
> 
> The traditional answer, and the answer applicable to jessie, has been
> "you can't do that, it is incorrect to run dbus-launch or use dbus-daemon
> in Xsession.d".

Ok, but as I explained, it is hard to realize that one is doing that...
I would have never thought that amixer would trigger dbus-launch for
instance.

And the relation between the "culprit" (amixer) and the effect (the
desktop being basically completely inaccessible) is far from obvious, so
it's very hard to even realize how something is getting wrong.

So we'd at least need to find a way to detect and notify about this
issue more prominently, so people know they're doing it wrong.

> Since dbus 1.10 (in stretch), we have mitigated this differently, by
> running dbus-launch from 75dbus_dbus-launch as you suggest,

? No, it is still prepended to $STARTUP only.

> anything started via D-Bus activation or as a systemd user service
> between 75dbus_dbus-launch and 95dbus_update-activation-env
> will not pick up an environment variable set by (for example)
> 90atk-adaptor.

I see.

Samuel