date:20141227

Le 26 déc. 2014 23:23, Ivo De Decker iv...@debian.org a écrit :

 Control: tags -1 moreinfo

 Hi Bastien,

 On Wed, Dec 24, 2014 at 12:01:29PM +0100, Bastien ROUCARIES wrote:
  Please unblock package imagemagick
 
  This fix a few security bug. Bugs are well isolated. Debdiff joined
 
  unblock imagemagick/8:6.8.9.9-4

 I haven't look at the debdiff (yet), but the build failed (again) on mips.
 This is the issue described in #770009. As the buildd 'ball' is down, and
it's
 unclear if it will come back, this issue should probably be fixed
properly,

Ok will do. It will nevertheless wait a little bit. The backported fixes
introduce a regression under emacs (render imagemagick for emacs useless)
Will fix also.

BTW i have prepared a stable queue for you (it is really painful to
backport)

Bastien

 even if it means disabling certain tests in mips, which take too long on
 machines without fpu. That's probably the only way we can be sure that
later
 (security) uploads during the lifetime of jessie will be able to build on
 mips.

 Cheers,

 Ivo

Bug#744753: anacron: Anacron not triggered when system resumes under systemd

tag 744753 + help
thanks

Hello,

Could somebody take care of this bug? I don't have the time for this
ATM.

Cheers,

Laurent Bigonville


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774011: lsar: wrong date for ARJ archives


Package: unar
Version: 1.8.1-3+b1
Severity: minor

The file in the attached ARJ archive was modified on 2014-12-10, but 
lsar shows 2022-04-08 as the date:


$ arj l moo.arj
ARJ32 v 3.10, Copyright (c) 1998-2004, ARJ Software Russia. [07 Aug 2014]

Processing archive: moo.arj
Archive created: 2014-12-27 12:06:58, modified: 2014-12-27 12:06:58
Filename   Original Compressed Ratio DateTime modified Attributes/GUA BPMGS
 -- -- - - -- -
moo   4  4 1.000 14-12-10 08:06:00 -rw--- ---   0
 -- -- -
1 files  4  4 1.000

$ lsar -l moo.arj
moo.arj: 2014-12-27 12:07:14.127 lsar[7185] File NSCalendarDate.m: 1546. In 
-[NSCalendarDate initWithYear:month:day:hour:minute:second:timeZone:] invalid 
hour given - 30
ARJ
Flags  File size   Ratio  Mode  Date   Time   Name
=  ==  =    == =  
 0. -   4   0.0%  None  2022-04-08 06:06  moo
(Flags: D=Directory, R=Resource fork, L=Link, E=Encrypted, @=Extended 
attributes)


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

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

Versions of packages unar depends on:
ii  dpkg  1.17.22
ii  gnustep-base-runtime  1.24.7-1
ii  libbz2-1.01.0.6-7+b2
ii  libc6 2.19-13
ii  libgcc1   1:4.9.2-10
ii  libgnustep-base1.24   1.24.7-1
ii  libicu52  52.1-6
ii  libobjc4  4.9.2-10
ii  libstdc++64.9.2-10
ii  libwavpack1   4.70.0-1
ii  zlib1g1:1.2.8.dfsg-2+b1

--
Jakub Wilk


moo.arj
Description: Binary data

Bug#771661: machine is completely unusable

2014-12-27 Thread Toni Mueller


Hi Ben,

On Sat, Dec 27, 2014 at 02:39:06AM +0100, Ben Hutchings wrote:
 1, Enable an emulated serial port for the VM, with output going to a
 file.

I modified the VM to have:

serial type='file'
  source path='/var/tmp/vm1-serial.log'/
  target port='0'/
/serial
console type='file'
  source path='/var/tmp/vm1-serial.log'/
  target type='serial' port='0'/
/console

 2. Enable a serial console on the kernel command line.

I added this to the end of the kernel boot line in the guest's
/boot/grub/grub.cfg:

   serial console=ttyS00,115200


 3. Set sysctl kernel.printk=7 (i.e. send all non-debug logging to the
 console).

I set this in the guest's /etc/sysctl.cfg

 4. Do whatever you have to do, to reproduce the hang.

All that is necessary is to say virsh start vm1.

I am confused because the output is really not that much more verbose
than the screnshots, but here you are:


[   22.224014] INFO: rcu_sched self-detected stall on CPU { 1}  (t=5251 jiffies 
g=-153 c=-154 q=307)
[   22.232010] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 
0, t=5252 jiffies, g=-153, c=-154, q=307)
[   22.232010] CPU: 0 PID: 122 Comm: systemd-udevd Not tainted 
3.16.0-0.bpo.4-686-pae #1 Debian 3.16.7-ckt2-1~bpo70+1
[   22.232010] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   22.232010] task: f6c96560 ti: f6cd6000 task.ti: f6cd6000
[   22.232010] Stack:
[   22.232010] Call Trace:
[   22.232010] Code: 00 d3 ff ff 80 e5 10 75 ee c1 e3 18 89 98 10 d3 ff ff 89 
f0 09 d0 80 ce 04 83 fe 02 0f 44 c2 8b 15 c4 8c 61 c1 89 82 00 d3 ff ff 89 f8 
50 9d 8d 74 26 00 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3
[   22.224014] CPU: 1 PID: 129 Comm: modprobe Not tainted 
3.16.0-0.bpo.4-686-pae #1 Debian 3.16.7-ckt2-1~bpo70+1
[   22.224014] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   22.224014] task: f6d23ab0 ti: f6d44000 task.ti: f6d44000
[   22.224014] Stack:
[   22.224014] Call Trace:
[   22.224014] Code: d3 e2 03 50 04 ec 0f b6 c0 5d c3 89 f6 8d bc 27 00 00 00 
00 55 89 e5 53 3e 8d 74 26 00 89 cb 0f b6 48 35 d3 e2 03 50 04 89 d8 ee 5b 5d 
c3 8d b6 00 00 00 00 55 89 e5 3e 8d 74 26 00 0f b6 50 36
[   22.224014] CPU: 1 PID: 129 Comm: modprobe Not tainted 
3.16.0-0.bpo.4-686-pae #1 Debian 3.16.7-ckt2-1~bpo70+1
[   22.224014] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   22.224014] task: f6d23ab0 ti: f6d44000 task.ti: f6d44000
[   22.224014] Stack:
[   22.224014] Call Trace:
[   22.224014] Code: 00 d3 ff ff 80 e5 10 75 ee c1 e3 18 89 98 10 d3 ff ff 89 
f0 09 d0 80 ce 04 83 fe 02 0f 44 c2 8b 15 c4 8c 61 c1 89 82 00 d3 ff ff 89 f8 
50 9d 8d 74 26 00 8b 5d f4 8b 75 f8 8b 7d fc 89 ec 5d c3
[   22.332011] CPU: 0 PID: 122 Comm: systemd-udevd Not tainted 
3.16.0-0.bpo.4-686-pae #1 Debian 3.16.7-ckt2-1~bpo70+1
[   22.332011] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   22.332011] task: f6c96560 ti: f6cd6000 task.ti: f6cd6000
[   22.332011] Stack:
[   22.332011] Call Trace:
[   22.332011] Code: 5d e9 38 a0 c0 ff 90 8d b4 26 00 00 00 00 55 89 e5 3e 8d 
74 26 00 ba 00 01 00 00 f0 66 0f c1 10 0f b6 ce 38 d1 75 04 5d c3 f3 90 0f b6 
10 38 ca 75 f7 5d c3 8d 76 00 8d bc 27 00 00 00 00 55 89
[   48.032012] BUG: soft lockup - CPU#0 stuck for 22s! [systemd-udevd:122]
[   48.032012] CPU: 0 PID: 122 Comm: systemd-udevd Not tainted 
3.16.0-0.bpo.4-686-pae #1 Debian 3.16.7-ckt2-1~bpo70+1
[   48.032012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   48.036010] BUG: soft lockup - CPU#1 stuck for 22s! [modprobe:129]
[   48.036010] CPU: 1 PID: 129 Comm: modprobe Not tainted 
3.16.0-0.bpo.4-686-pae #1 Debian 3.16.7-ckt2-1~bpo70+1
[   48.036010] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   48.036010] task: f6d23ab0 ti: f6d44000 task.ti: f6d44000
[   48.036010] Stack:
[   48.036010] Call Trace:
[   48.036010] Code: 00 00 8d bf 00 00 00 00 89 48 04 89 10 c3 8d 76 00 8d bc 
27 00 00 00 00 83 ec 08 89 74 24 04 89 c6 89 1c 24 89 d3 8b 00 8b 56 04 f0 0f 
c7 0e 75 fa 8b 1c 24 8b 74 24 04 83 c4 08 c3 8d b6 00 00
[   48.032012] task: f6c96560 ti: f6cd6000 task.ti: f6cd6000
[   48.032012] Stack:
[   48.032012] Call Trace:
[   48.032012] Code: 5d e9 38 a0 c0 ff 90 8d b4 26 00 00 00 00 55 89 e5 3e 8d 
74 26 00 ba 00 01 00 00 f0 66 0f c1 10 0f b6 ce 38 d1 75 04 5d c3 f3 90 0f b6 
10 38 ca 75 f7 5d c3 8d 76 00 8d bc 27 00 00 00 00 55 89

At this point, I shut the VM down because it did not seem to produce
any more useful information.



Kind regards,
--Toni++


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774012: systemd: Program terminated with signal SIGFPE, Arithmetic exception.

2014-12-27 Thread Paul Menzel

Package: systemd
Version: 215-8
Severity: important
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=87349

Dear Debian folks,


using Debian Sid/unstable with systemd 215-8, I still have problems that
there are time-outs between systemd and D-Bus, even with the current
D-Bus 1.8.12 [1]. Experiencing this again, where
`systemd-logind.service` was not started, I was able to log in on tty1
but in the end I was unable to run any `sudo systemctl` commands as they
timed out. I also was unable to reboot or halt the system.

Somewhere in that situation systemd also crashed with an arithmetic
exception; logged as `Caught FPE` in `/var/log/syslog`).

I reported this issue upstream [2] but there has been no response for
almost two weeks. The backtrace is pasted in the original upstream bug
report and in this message at the end.


Thanks,

Paul


[1] https://bugs.freedesktop.org/show_bug.cgi?id=87424
Time-out problems during boot with systemd
[2] https://bugs.freedesktop.org/show_bug.cgi?id=87349

-- Package-specific info:

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.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/bash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-58
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-4
ii  libc6   2.19-13
ii  libcap2 1:2.24-6
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-4
ii  libgcrypt20 1.6.2-4+b1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-8
ii  mount   2.25.2-4
ii  sysv-rc 2.88dsf-58
ii  udev215-8
ii  util-linux  2.25.2-4

Versions of packages systemd recommends:
ii  dbus1.8.12-3
ii  libpam-systemd  215-8

Versions of packages systemd suggests:
pn  systemd-ui  none

-- no debconf information

-- Backtrace
Thread 1 (Thread 0xb73417c0 (LWP 3020)):
#0  0xb7650d3c in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7603bb6 in raise (sig=8) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = optimized out
resultvar = optimized out
pid = optimized out
#2  0xb7686e6b in crash.lto_priv.235 (sig=8) at ../src/core/main.c:158
rl = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615}
sa = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0 repeats 32 times}}, sa_flags = 0, 
  sa_restorer = 0x0}
pid = optimized out
__func__ = crash
__PRETTY_FUNCTION__ = crash
#3  signal handler called
No symbol table info available.
#4  0xb772fcdf in manager_print_jobs_in_progress (m=0xb79c6bd0) at 
../src/core/manager.c:170
job_of_n = 0x0
j = optimized out
counter = 0
cylon = 
|\000\000\000\060ᶷ\000\000\000\000\001\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\001\000\000
time = 
\002\000\000\000\003\000\000\000\005\000\000\000\001\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\005\000\000\000\000M\362\261\v\000\000\000\210P\245\267\071Hk\267h:{\267\005\000\000\000\v\000\000\000\210P\245\267
limit = no limit, '\000' repeats 55 times
x = optimized out
i = 0x0
cylon_pos = optimized out
#5  manager_dispatch_jobs_in_progress (source=0xb7b64fe8, usec=432972905, 
userdata=0xb79c6bd0) at ../src/core/manager.c:1846
m = 0xb79c6bd0
r = optimized out
next = optimized out
__PRETTY_FUNCTION__ = manager_dispatch_jobs_in_progress
#6  0xb76a157d in source_dispatch (s=0xb7b64fe8) at 
../src/libsystemd/sd-event/sd-event.c:2024
r = optimized out
__PRETTY_FUNCTION__ = source_dispatch
__func__ = source_dispatch
#7  0xb76a6b94 in sd_event_run (e=optimized out, timeout=optimized out) at 
../src/libsystemd/sd-event/sd-event.c:2314
ev_queue = optimized out
ev_queue_max = optimized out
p = optimized out
r = optimized out
i = optimized out
m = 1
timedout = false
__PRETTY_FUNCTION__ = sd_event_run
#8  0xb7731f13 in manager_loop (m=0xb79c6bd0) at ../src/core/manager.c:1912
wait_usec = 18446744073709551615
rl = {interval = 100, begin = 432639580, burst = 5, num = 26074}
__PRETTY_FUNCTION__ = manager_loop
__func__ = manager_loop
#9  0xb7685062 in main (argc=1, argv=0xbfe55314) at ../src/core/main.c:1743
m = optimized out
---Type return to continue, or q return to quit---
r = optimized out
retval = 1
before_startup = optimized out
after_startup = optimized out
timespan =

Bug#774013: FTBFS: script `postrm' has bad permissions 644

2014-12-27 Thread Jonathan Wiltshire

Package: rsbackup
Version: 1.1-3
Severity: serious
Tags: patch
Justification: FTBFS regression

rsbackup fails to build from source on all architectures, which is a
regression. Tail of the log from amd64:

cd debian/rsbackup  \
  find -name DEBIAN -prune -o -type f -print \
| sed 's/^\.\///' \
| xargs md5sum  DEBIAN/md5sums
dpkg-gencontrol -isp -prsbackup -Pdebian/rsbackup \
-Tdebian/substvars.rsbackup
dpkg-gencontrol: warning: -isp is deprecated; it is without effect
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is 
not NFS-safe
chown -R root:root debian/rsbackup
chmod -R g-ws debian/rsbackup
dpkg --build debian/rsbackup ..
dpkg-deb: error: maintainer script `postrm' has bad permissions 644 (must be 
=0555 and =0775)
debian/rules:39: recipe for target 'binary-rsbackup' failed
make: *** [binary-rsbackup] Error 2

debian/rsbackup.postrm was introduced to fix #773181, but sure enough it has
mode 0644. debian/rules just calls `cp' to install the file, hence the error.

The attached patch replaces `cp' with `install' so that it's not so fragile
in future regardless of source file mode.

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

Kernel: Linux 3.16.0-4-amd64 (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: systemd (via /run/systemd/system)
--- debian/rules.orig	2014-12-27 11:35:56.756080121 +
+++ debian/rules	2014-12-27 11:34:54.720105281 +
@@ -47,8 +47,8 @@
 	mkdir -p debian/${PACKAGE}/var/log/backup
 	mkdir -p debian/${PACKAGE}/usr/share/doc-base
 	cp debian/${PACKAGE}.conffiles debian/${PACKAGE}/DEBIAN/conffiles
-	cp debian/${PACKAGE}.postinst debian/${PACKAGE}/DEBIAN/postinst
-	cp debian/${PACKAGE}.postrm debian/${PACKAGE}/DEBIAN/postrm
+	install debian/${PACKAGE}.postinst debian/${PACKAGE}/DEBIAN/postinst
+	install debian/${PACKAGE}.postrm debian/${PACKAGE}/DEBIAN/postrm
 	cp tools/rsbackup.hourly debian/${PACKAGE}/etc/cron.hourly/rsbackup
 	cp tools/rsbackup.daily debian/${PACKAGE}/etc/cron.daily/rsbackup
 	cp tools/rsbackup.weekly debian/${PACKAGE}/etc/cron.weekly/rsbackup

Bug#774014: Segfault after testing connectivity

2014-12-27 Thread Vincent Bernat

Package: python-libconcord
Version: 1.1-2
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

After testing connectivity, python-libconcord segfaults:

*** buffer overflow detected ***: python terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x7303f)[0x7f097257f03f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f0972602147]
/lib/x86_64-linux-gnu/libc.so.6(+0xf4360)[0x7f0972600360]
/lib/x86_64-linux-gnu/libc.so.6(+0xf3869)[0x7f09725ff869]
/lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0x89)[0x7f0972582109]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x1ca2)[0x7f0972553ec2]
/lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x88)[0x7f09725ff8f8]
/lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7f09725ff84d]
/usr/lib/libconcord.so.3(_Z4PostPhjPKcR11TRemoteInfobbbPSsS4_+0x375)[0x7f0966b2a985]
/usr/lib/libconcord.so.3(post_connect_test_success+0x77)[0x7f0966b27407]
/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call_unix64+0x4c)[0x7f0972089dc0]
/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call+0x2f8)[0x7f0972089828]
/usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so(_ctypes_callproc+0x495)[0x7f09722f6055]
/usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so(+0x119b2)[0x7f09722fa9b2]
python(PyEval_EvalFrameEx+0xfe9)[0x4cb879]
python(PyEval_EvalFrameEx+0xb2a)[0x4cb3ba]
python[0x4e6cf0]
python[0x5052e8]
python(PyEval_CallObjectWithKeywords+0x6b)[0x4d28cb]
python[0x5bd472]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f09731e00a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f09725f1ccd]

This is quite recent. I have used congruity without a problem one or
two months ago.

Here is a full backtrace:

#0  0x7fae55716107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 21355
selftid = 21362
#1  0x7fae557174e8 in __GI_abort () at abort.c:89
save_stage = 2
act = {
  __sigaction_handler = {
sa_handler = 0x2d303030,
sa_sigaction = 0x2d303030
  },
  sa_mask = {
__val = {3474076752553600614, 8659703141076316209, 
3472328296227676272, 3472339291342909488, 2314885530818457632, 
2314885530818453536, 8751468634664083488, 7568964844005712755, 
3689962539751649127, 7292506702445175650, 3689072854590436406, 
7291662475097157987, 3329345833768138338, 735262552734523747, 
7149242536436000311, 0}
  },
  sa_flags = 52,
  sa_restorer = 0x7fae4831a8a0
}
sigs = {
  __val = {32, 0 repeats 15 times}
}
#2  0x7fae55754044 in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x7fae558446ab *** %s ***: %s terminated\n) at 
../sysdeps/posix/libc_fatal.c:175
ap = {{
gp_offset = 32,
fp_offset = 0,
overflow_arg_area = 0x7fae4831a8b0,
reg_save_area = 0x7fae4831a840
  }}
fd = 14
on_2 = optimized out
list = optimized out
nlist = optimized out
cp = optimized out
written = optimized out
#3  0x7fae557d7147 in __GI___fortify_fail (msg=msg@entry=0x7fae55844642 
buffer overflow detected) at fortify_fail.c:31
No locals.
#4  0x7fae557d5360 in __GI___chk_fail () at chk_fail.c:28
No locals.
#5  0x7fae557d4869 in _IO_str_chk_overflow (fp=optimized out, 
c=optimized out) at vsprintf_chk.c:33
No locals.
#6  0x7fae55757109 in __GI__IO_default_xsputn (f=0x7fae4831aee0, 
data=optimized out, n=848) at genops.c:480
s = 0x7fae40003ba0 
AUSER=vincent%2Ebernat;CookieKeyValue={----, 'E' repeats 
12 times, 
}{F46BFA72-E0D5-4D14-84DF-3C0CCF64A22B}{C5783AFA-710E-48B6-91B4-A2A48C169F37}
more = 153
#7  0x7fae55728ec2 in _IO_vfprintf_internal (s=s@entry=0x7fae4831aee0, 
format=optimized out, format@entry=0x7fae49cfffc0 POST /%s 
HTTP/1.1\r\nUser-Agent: HarmonyBrowser/7.3.0 (Build 15; UpdatedFrom 7.3.0.15; 
Skin logitech; Windows XP 5.1; x86; en; rv: 1.8.0.2) 
Gecko/20060125\r\nContent-Type:  application/x-www-form-urlencod..., 
ap=ap@entry=0x7fae4831b018) at vfprintf.c:1636
len = 848
string_malloced = optimized out
step0_jumps = {0, -9241, -2673, -2586, 2622, 2709, 2030, 2306, 3013, 
-574, -238, 3350, 2525, 3622, -2492, -14796, -727, 1123, 1065, 1643, -14028, 
-28, 1472, -10234, -10158, -15462, 1169, 3525, 3525, 2203}
space = 0
is_short = 0
use_outdigits = 0
step1_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, -574, -238, 3350, 2525, 3622, 
-2492, -14796, -727, 1123, 1065, 1643, -14028, -28, 1472, -10234, -10158, 
-15462, 1169, 3525, 3525, 0}
group = 0
prec = 848
step2_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -238, 3350, 2525, 3622, 
-2492, -14796, -727, 1123, 1065, 1643, -14028, -28, 1472, -10234, -10158, 
-15462, 1169, 3525, 3525, 0}
string = 0x7fae400038e8 ASPSESSIONIDACABBABS=NNNLOHICMFNLIPGPHFNFJNIA;

Bug#774015: arj: free(): invalid pointer


Package: arj
Version: 3.10.22-12
Usertags: afl

ARJ crashes on the attached (slightly corrupted) ARJ file:

$ arj t crash.arj
ARJ32 v 3.10, Copyright (c) 1998-2004, ARJ Software Russia. [08 Aug 2014]

Processing archive: crash.arj
Archive created: 2014-12-27 10:40:05, modified: 2014-12-27 10:40:05
Testing limerickBad file data, CRC error!
1 file(s)

Found 1 error(s)!
*** Error in `arj': free(): invalid pointer: 0x017e3200 ***
Aborted


This bug was found using American fuzzy lop:
https://packages.debian.org/experimental/afl


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages arj depends on:
ii  libc6  2.19-13

--
Jakub Wilk


crash.arj
Description: Binary data

Bug#774016: unar: null pointer dereference on corrupted ARJ file


Package: unar
Version: 1.8.1-3+b1
Usertags: afl

unar dereferences null pointer when trying to unpack the attached 
(slightly corrupted) ARJ file:


$ unar crash.arj
crash.arj: ARJ
 limerick  (191 B)... Segmentation fault


This bug was found using American fuzzy lop:
https://packages.debian.org/experimental/afl

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

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

Versions of packages unar depends on:
ii  dpkg  1.17.22
ii  gnustep-base-runtime  1.24.7-1
ii  libbz2-1.01.0.6-7+b2
ii  libc6 2.19-13
ii  libgcc1   1:4.9.2-10
ii  libgnustep-base1.24   1.24.7-1
ii  libicu52  52.1-6
ii  libobjc4  4.9.2-10
ii  libstdc++64.9.2-10
ii  libwavpack1   4.70.0-1
ii  zlib1g1:1.2.8.dfsg-2+b1

--
Jakub Wilk


crash.arj
Description: Binary data

Bug#771661: machine is completely unusable

2014-12-27 Thread Toni Mueller



Hi Ben,

I tweaked it a bit, and now I get much more telling messages:


[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-0.bpo.4-686-pae 
(debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP 
Debian 3.16.7-ckt2-1~bpo70+1 (2014-12-08)
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x6cbfdfff] usable
[0.00] BIOS-e820: [mem 0x6cbfe000-0x6cbf] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] Hypervisor detected: KVM
[0.00] e820: last_pfn = 0x6cbfe max_arch_pfn = 0x100
[0.00] PAT not supported by CPU.
[0.00] found SMP MP-table at [mem 0x000f1e90-0x000f1e9f] mapped at 
[c00f1e90]
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00] init_memory_mapping: [mem 0x3720-0x373f]
[0.00] init_memory_mapping: [mem 0x3400-0x371f]
[0.00] init_memory_mapping: [mem 0x0010-0x33ff]
[0.00] init_memory_mapping: [mem 0x3740-0x375fdfff]
[0.00] RAMDISK: [mem 0x361ac000-0x370cdfff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F1D10 14 (v00 BOCHS )
[0.00] ACPI: RSDT 0x6CBFE410 34 (v01 BOCHS  BXPCRSDT 0001 BXPC 
0001)
[0.00] ACPI: FACP 0x6CBFFF80 74 (v01 BOCHS  BXPCFACP 0001 BXPC 
0001)
[0.00] ACPI: DSDT 0x6CBFE450 001135 (v01 BOCHS  BXPCDSDT 0001 BXPC 
0001)
[0.00] ACPI: FACS 0x6CBFFF40 40
[0.00] ACPI: SSDT 0x6CBFF6C0 00087A (v01 BOCHS  BXPCSSDT 0001 BXPC 
0001)
[0.00] ACPI: APIC 0x6CBFF5D0 80 (v01 BOCHS  BXPCAPIC 0001 BXPC 
0001)
[0.00] ACPI: HPET 0x6CBFF590 38 (v01 BOCHS  BXPCHPET 0001 BXPC 
0001)
[0.00] 854MB HIGHMEM available.
[0.00] 885MB LOWMEM available.
[0.00]   mapped low ram: 0 - 375fe000
[0.00]   low ram: 0 - 375fe000
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 0:375fd001, primary cpu clock
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   Normal   [mem 0x0100-0x375fdfff]
[0.00]   HighMem  [mem 0x375fe000-0x6cbfdfff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x6cbfdfff]
[0.00] Using APIC driver default
[0.00] ACPI: PM-Timer IO Port: 0xb008
[0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[0.00] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
[0.00] ACPI: IOAPIC (id[0x00] address[0xfec0] gsi_base[0])
[0.00] IOAPIC[0]: apic_id 0, version 17, address 0xfec0, GSI 0-23
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
[0.00] Using ACPI (MADT) for SMP configuration information
[0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0
[0.00] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
[0.00] PM: Registered nosave memory: [mem 0x0009f000-0x0009]
[0.00] PM: Registered nosave memory: [mem 0x000a-0x000e]
[0.00] PM: Registered nosave memory: [mem 0x000f-0x000f]
[0.00] e820: [mem 0x6cc0-0xfeffbfff] available for PCI devices
[0.00] Booting paravirtualized kernel on KVM
[0.00] setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:2 
nr_node_ids:1
[0.00] PERCPU: Embedded 14 pages/cpu @f75d8000 s35328 r0 d22016 u57344
[0.00] KVM setup async PF for cpu 0
[0.00] kvm-stealtime: cpu 0, msr 375db280
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 443568
[0.00] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-3.16.0-0.bpo.4-686-pae 
root=UUID=c707415e-9478-46ac-b02e-2ac1c4a70087 ro vga=normal console=ttyS0
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[

Bug#774017: unblock: lzo2/2.08-1.2

2014-12-27 Thread Jonathan Wiltshire

Package: release.debian.org
Severity: normal
Tags: d-i
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lzo2

Simon McVittie NMUd lzo2 to fix a crash in openvpn, RC bug #757037. The
attached debdiff covers -1.1 and -1.2 since the first fix was incomplete.

Unblocked, but needs a kibi-ack for the udeb please.

unblock-udeb lzo2/2.08-1.2

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

Kernel: Linux 3.16.0-4-amd64 (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: systemd (via /run/systemd/system)
diff -Nru lzo2-2.08/debian/changelog lzo2-2.08/debian/changelog
--- lzo2-2.08/debian/changelog	2014-07-15 01:03:18.0 +
+++ lzo2-2.08/debian/changelog	2014-12-20 17:50:47.0 +
@@ -1,3 +1,26 @@
+lzo2 (2.08-1.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Adjust patch from previous upload so the modern C code path still
+defines some typedefs: lzo_memops_TU1p is a pointer to unsigned byte
+(used by the byteswapping implementation on non-powerpc big-endian
+architectures), and lzo_memops_TU2p and lzo_memops_TU4p
+are pointers to unsigned 2- and 4-byte quantities (needed by the
+powerpc assembler implementation). Together, these fix FTBFS on
+big-endian platforms. (Closes: #773580)
+
+ -- Simon McVittie s...@debian.org  Sat, 20 Dec 2014 17:50:38 +
+
+lzo2 (2.08-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Replace liblzo's reinvention of memcpy() with calls to memcpy().
+gcc already knows how to inline memcpy calls with constant n,
+and also gets the alignment constraints right, avoiding incorrect
+unaligned accesses on armel (Closes: #757037)
+
+ -- Simon McVittie s...@debian.org  Tue, 16 Dec 2014 23:35:36 +
+
 lzo2 (2.08-1) unstable; urgency=low
 
   * New upstream release (closes: #752861) (CVE-2014-4607)
diff -Nru lzo2-2.08/debian/patches/0001-Conditionally-replace-reinvention-of-memcpy-with-cal.patch lzo2-2.08/debian/patches/0001-Conditionally-replace-reinvention-of-memcpy-with-cal.patch
--- lzo2-2.08/debian/patches/0001-Conditionally-replace-reinvention-of-memcpy-with-cal.patch	1970-01-01 00:00:00.0 +
+++ lzo2-2.08/debian/patches/0001-Conditionally-replace-reinvention-of-memcpy-with-cal.patch	2014-12-20 17:50:47.0 +
@@ -0,0 +1,366 @@
+From: Simon McVittie s...@debian.org
+Date: Sat, 20 Dec 2014 17:50:27 +
+Subject: Conditionally replace reinvention of memcpy() with calls to memcpy()
+
+gcc already knows how to inline memcpy calls with constant n,
+and also gets the alignment constraints right, avoiding incorrect
+unaligned accesses on armel.
+
+Unconditionally define LZO_MEMOPS_GET_NE64 since it's trivial
+to do in terms of LZO_MEMOPS_COPY8.
+
+I've made the modern C version conditional since lzo seems to aim
+to be portable to anything and everything, but it would probably
+be better off just requiring a compiler from this century and
+a set of correctly working memwhatever() implementations.
+
+Bug-Debian: https://bugs.debian.org/757037
+---
+ minilzo/minilzo.c | 76 ++-
+ src/lzo_conf.h|  2 --
+ src/lzo_func.h| 71 +++
+ 3 files changed, 125 insertions(+), 24 deletions(-)
+
+diff --git a/minilzo/minilzo.c b/minilzo/minilzo.c
+index ab2be5f..146b383 100644
+--- a/minilzo/minilzo.c
 b/minilzo/minilzo.c
+@@ -3354,6 +3354,49 @@ lzo_bitops_unused_funcs(void)
+ LZO_UNUSED_FUNC(lzo_bitops_unused_funcs);
+ }
+ 
++/* Modern compilers know that memcpy() and memset() with constant n can be
++ * inlined, and do so without violating alignment constraints on e.g. ARMv5,
++ * unlike the macros below. */
++#if LZO_CFG_MODERN_C+0
++
++/* ISO C says char pointers of any signedness can alias anything
++ * (C11 draft 1570, paragraph 6.5.7) so they are safe for this use */
++typedef unsigned char *lzo_memops_TU1p;
++
++/* Used by powerpc assembler implementations of byteswapping */
++#if (LZO_OPT_UNALIGNED16)
++typedef lzo_uint16_t __lzo_may_alias lzo_memops_TU2;
++typedef lzo_memops_TU2 *lzo_memops_TU2p;
++#endif
++
++/* Used by powerpc assembler implementations of byteswapping */
++#if (LZO_OPT_UNALIGNED32)
++typedef lzo_uint32_t __lzo_may_alias lzo_memops_TU4;
++typedef lzo_memops_TU4 *lzo_memops_TU4p;
++#endif
++
++#define LZO_MEMOPS_SET1(dd,cc) memset(dd, cc, 1)
++#define LZO_MEMOPS_SET2(dd,cc) memset(dd, cc, 2)
++#define LZO_MEMOPS_SET3(dd,cc) memset(dd, cc, 3)
++#define LZO_MEMOPS_SET4(dd,cc) memset(dd, cc, 4)
++/* lzo does not appear to use these macros between overlapping buffers
++ * in practice, so memmove() (which is not inlined by gcc) is unnecessary. */
++#define

Bug#771661: machine is completely unusable

2014-12-27 Thread Toni Mueller



Hi Ben,

possibly unrelated, but neither the kernels of the Ubuntu installers for
12.04 and 14.04, nor the kernel for Fedora 21 installer, even boot on my
VM. I reckoned that you might be interested, being a kernel hacker.
CentOS 6.5 or OpenBSD 5.6 don't have a problem, though.


Kind regards,
--Toni++


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774000: Graphics and non fixed fonts broken after hibernation

2014-12-27 Thread Julien Cristau

On Sat, Dec 27, 2014 at 00:19:47 +0100, Santiago Garcia Mantinan wrote:

 Package: xserver-xorg-video-intel
 Version: 2:2.21.15-2+b2
 Severity: normal
 
 Hi!
 
 I'm experiencing this on Jessie's version 2:2.21.15-2+b2 as well as on the
 version on experimental (2:2.99.917-1~exp1).  I'm currently running Jessie
 up to date.  I don't know if this is a fault on the driver or on the kernel
 side, I have tested several kernels up to the 3.18 on experimental, it
 happens with all of them.
 
Please get logs from the latest kernel and X driver version and use them
to file a bug upstream following
https://01.org/linuxgraphics/documentation/how-report-bugs
Then let us know the bug number for tracking.

Thanks,
Julien


signature.asc
Description: Digital signature

Bug#774007: xserver-xorg-video-intel: Graphics acceleration breaks after playing a video in chromium

2014-12-27 Thread Julien Cristau

On Sat, Dec 27, 2014 at 00:57:46 -0800, Alan Fisher wrote:

 Package: xserver-xorg-video-intel
 Version: 2:2.99.917-1~exp1
 Severity: serious
 
 Dear Maintainer,
 
 Trying to play an HTML5 video in Chromium causes the GPU to hang, and
 hardware acceleration to become disabled. This appears to be reproducible
 100% of the time on an amd64 Thinkpad X61s but never reproducible on an
 i386 Thinkpad X60s. I've tested with both the xserver-xorg-video-intel
 package in testing, as well as the package in experimental. Both appear
 to have the same problem.
 
Please report this upstream following
https://01.org/linuxgraphics/documentation/how-report-bugs
Let us know the bug number for tracking.

Thanks,
Julien


signature.asc
Description: Digital signature

Bug#774015: arj: free(): invalid pointer


* Jakub Wilk jw...@debian.org, 2014-12-27, 12:53:

This bug was found using American fuzzy lop:
https://packages.debian.org/experimental/afl


Disclaimer: I don't have spare CPU cycles, so I fuzzed only till the 
first crash (which took a few minutes at most). It's likely that 
extensive fuzzing would discover more interesting crashers. I'd 
encourage ARJ maintainers to perform fuzzing with AFL on their own. :-)


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774016: unar: null pointer dereference on corrupted ARJ file


* Jakub Wilk jw...@debian.org, 2014-12-27, 13:02:

This bug was found using American fuzzy lop:
https://packages.debian.org/experimental/afl


To clarify, I didn't fuzz unar itself. I did fuzz ARJ, and then tested 
the discovered crasher (see #774015) on unar.


I'd encourage unar maintainers to perform fuzzing with AFL on their own. 
:-)


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773577: libssh: CVE-2014-8132: Double free on dangling pointers in initial key exchange packet

On Sat, 20 Dec 2014 08:18:29 +0100 Salvatore Bonaccorso
car...@debian.org wrote:

 Hi,

Hello,

 the following vulnerability was published for libssh.
 
 CVE-2014-8132[0]:
 Possible double free on a dangling pointer with crafted kexinit packet

The fix is available at:
http://git.libssh.org/projects/libssh.git/commit/?id=c2aed4ca78030d9014a890cb4370e6dc8264823f

Cheers,

Laurent Bigonville


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773945: gpaste: please add a debug symbols package

2014-12-27 Thread Jérémy Lal

Le vendredi 26 décembre 2014 à 12:48 +0800, Paul Wise a écrit :
 Source: gpaste
 Version: 3.14-1
 Severity: wishlist
 Usertags: debug crash
 
 I had the gpaste daemon crash randomly. I would like to be able to file
 a bug about it but the backtrace isn't very useful without debug symbols
 so please add a -dbg package containing debug symbols for gpaste.

Hi,

libgpaste2-dbg package has been added to collab-maint's CVS of gpaste.

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765471: Possible workaround

2014-12-27 Thread Scott Bennett

I'm having the same issue with OpenArena.  I'm using the same versions as the 
OP.  I'm running Kubuntu 14.10 on an AMD A6-3600 processor with AMD Radeon 
HD6530D graphics acceleration.  I have  an ALC662 audio chipset and an 
RTL8111-type Gigabit Ethernet controller.

In looking at the backtrace, I also noticed that most of the traces seemed to 
have something to do with PulseAudio.  One thing I tried was turning off 
OpenAL, and since I've done that I have not been able to reproduce the problem 
in over an hour of playing... it never took longer than five minutes before.

I only use multiplayer mode, so I can't speak to whether local mode has the 
same issue.

Thanks,
Scott


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774018: libpython2.7-dbg: dangling symlink /usr/share/man/man1/x86_64-linux-gnu-python2.7-dbg-config.1.gz

2014-12-27 Thread Vincent Lefevre

Package: libpython2.7-dbg
Version: 2.7.9-1
Severity: normal

/usr/share/man/man1/x86_64-linux-gnu-python2.7-dbg-config.1.gz
is a dangling symlink:

ypig% ls -l /usr/share/man/man1/x86_64-linux-gnu-python2.7-dbg-config.1.gz
lrwxrwxrwx 1 root root 38 2014-12-11 09:55:04 
/usr/share/man/man1/x86_64-linux-gnu-python2.7-dbg-config.1.gz - 
x86_64-linux-gnu-python2.7-config.1.gz

ypig% ls -lL /usr/share/man/man1/x86_64-linux-gnu-python2.7-dbg-config.1.gz
ls: cannot access 
/usr/share/man/man1/x86_64-linux-gnu-python2.7-dbg-config.1.gz: No such file or 
directory

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

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

Versions of packages libpython2.7-dbg depends on:
ii  libbz2-1.0   1.0.6-7+b2
ii  libc62.19-13
ii  libdb5.3 5.3.28-7+b1
ii  libexpat12.1.0-6+b3
ii  libffi6  3.1-2+b2
ii  libncursesw5 5.9+20140913-1+b1
ii  libpython2.7-stdlib  2.7.9-1
ii  libreadline6 6.3-8+b2
ii  libsqlite3-0 3.8.7.2-1
ii  libssl1.0.0  1.0.1j-1
ii  libtinfo55.9+20140913-1+b1
ii  multiarch-support2.19-13
ii  zlib1g   1:1.2.8.dfsg-2+b1

libpython2.7-dbg recommends no packages.

Versions of packages libpython2.7-dbg suggests:
pn  python2.7-gdbm-dbg  none
pn  python2.7-tk-dbgnone

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774019: libpython3.4-dbg: danglink symlink /usr/share/man/man1/x86_64-linux-gnu-python3.4-dbg-config.1.gz

2014-12-27 Thread Vincent Lefevre

Package: libpython3.4-dbg
Version: 3.4.2-3
Severity: normal

/usr/share/man/man1/x86_64-linux-gnu-python3.4-dbg-config.1.gz
is a dangling symlink:

ypig% ls -l /usr/share/man/man1/x86_64-linux-gnu-python3.4-dbg-config.1.gz
lrwxrwxrwx 1 root root 39 2014-12-02 16:14:33 
/usr/share/man/man1/x86_64-linux-gnu-python3.4-dbg-config.1.gz - 
x86_64-linux-gnu-python3.4m-config.1.gz

ypig% ls -lL /usr/share/man/man1/x86_64-linux-gnu-python3.4-dbg-config.1.gz
ls: cannot access 
/usr/share/man/man1/x86_64-linux-gnu-python3.4-dbg-config.1.gz: No such file or 
directory

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

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

Versions of packages libpython3.4-dbg depends on:
ii  libbz2-1.0   1.0.6-7+b2
ii  libc62.19-13
ii  libdb5.3 5.3.28-7+b1
ii  libexpat12.1.0-6+b3
ii  libffi6  3.1-2+b2
ii  liblzma5 5.1.1alpha+20120614-2+b3
ii  libmpdec22.4.1-1
ii  libncursesw5 5.9+20140913-1+b1
ii  libpython3.4-stdlib  3.4.2-3
ii  libreadline6 6.3-8+b2
ii  libsqlite3-0 3.8.7.2-1
ii  libssl1.0.0  1.0.1j-1
ii  libtinfo55.9+20140913-1+b1
ii  multiarch-support2.19-13
ii  zlib1g   1:1.2.8.dfsg-2+b1

libpython3.4-dbg recommends no packages.

libpython3.4-dbg suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774021: ent: New upstream version with better chi-square test

2014-12-27 Thread Ron

Package: ent
Version: 1.1debian-4
Severity: normal

Hi,

So it appears the upstream ent source (since 2008?) now has
a much better chi-square calculation.  It would be awesome
if we could get that into the packaged version too.

The source for that is linked from here:
https://www.fourmilab.ch/random/

and available here:
http://www.fourmilab.ch/random/random.zip

It's unfortunately not versioned in any way that makes it
obvious when or what was updated, but looking at the diff
shows the new chi-square code is the main difference.

Where I get results like this from the debian version:

 Chi square distribution for 655360 samples is 258.54, and randomly
 would exceed this value 50.00 percent of the times.

The new upstream one gives me a less approximate:

 Chi square distribution for 655360 samples is 258.54, and randomly
 would exceed this value 42.64 percent of the times.


Thanks for your work on looking after this package!

  Cheers,
  Ron


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773421: lxc: can't start container

2014-12-27 Thread Hleb Valoshka

On 12/26/14, Daniel Baumann daniel.baum...@progress-technologies.net wrote:

 please do not run cgmanager *and* systemd, use either or.

Daniel, please, reread initial message. I do NOT use systemd as pid 1,
I use good old sysv init:

ii  libpam-systemd:amd64  215-8
  amd64system and service manager - PAM module
ii  libsystemd0:amd64 215-8
  amd64systemd utility library
ii  libsystemd0:i386  215-8
  i386 systemd utility library
ii  systemd   215-8
  amd64system and service manager
ii  systemd-shim  9-1
  amd64shim for systemd
ii  sysv-rc   2.88dsf-58
  all  System-V-like runlevel change mechanism
ii  sysvinit  2.88dsf-58
  amd64System-V-like init utilities - transitional
package
ii  sysvinit-core 2.88dsf-58
  amd64System-V-like init utilities
ii  sysvinit-utils2.88dsf-58
  amd64System-V-like utilities

I've only noted that there are no such problem with systemd as init
because my colleague  has jessie with systemd as pid 1 and he can
start lxc containers without any problem.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774022: manpages: some man pages have references to console(4), which no longer exists

2014-12-27 Thread Vincent Lefevre

Package: manpages
Version: 3.74-1
Severity: normal

The following man pages have references to console(4).
  * charsets(7) [in SEE ALSO]
  * tty(4) [in SEE ALSO]
  * vcs(4) twice [in DESCRIPTION and SEE ALSO]

But apt-file search console.4 says that /usr/share/man/man4/console.4.gz
is provided by the console-tools package (e.g. in wheezy), which is
no longer in Debian (testing or unstable) and has been replaced by
the kbd package.

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

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

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.7.0.2-4

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771661: machine is completely unusable

2014-12-27 Thread Ben Hutchings

On Sat, 2014-12-27 at 11:20 +, Toni Mueller wrote:
[...]
 I am confused because the output is really not that much more verbose
 than the screnshots, but here you are:
 
 
 [   22.224014] INFO: rcu_sched self-detected stall on CPU { 1}  (t=5251 
 jiffies g=-153 c=-154 q=307)

What happened to the first 22 seconds of the log?

 [   22.232010] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected 
 by 0, t=5252 jiffies, g=-153, c=-154, q=307)
 [   22.232010] CPU: 0 PID: 122 Comm: systemd-udevd Not tainted 
 3.16.0-0.bpo.4-686-pae #1 Debian 3.16.7-ckt2-1~bpo70+1
 [   22.232010] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 [   22.232010] task: f6c96560 ti: f6cd6000 task.ti: f6cd6000
 [   22.232010] Stack:
 [   22.232010] Call Trace:
[...]

I don't understand why the stack information is not printed here.
Please add 'debug' to the kernel command line; that should force it to
really log everything.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Bug#773980: libmagickcore-6.q16-2: 8:6.8.9.9-4 breaks images in GNU Emacs 24 (displayed as single colour rectangles)

2014-12-27 Thread Adam Sjøgren

Bastien writes:

 On Fri, Dec 26, 2014 at 10:24 PM, Adam Sjøgren a...@koldfront.dk wrote:
 Bastien writes:

 When displaying an image in GNU Emacs 24 (package emacs24), after
 upgrading from ImageMagick 8:6.8.9.9-3 to 8:6.8.9.9-4, images with
 :type 'imagemagick are displayed as single colour rectangles.

 Thanks could you get the exact command running ?

 I don't understand your question.

 I suppose emacs execute imagmagick. Thus that is the command (shell)
 and parameter that emacs use ?

I don't think Emacs executes any ImageMagick commands - Emacs is linked
to the ImageMagick libraries, which is why I reported the bug against
libmagickcore-6, and not on the package with the binaries.

I.e.:

  $ ldd /usr/bin/emacs24 | grep -i magick
  libMagickWand-6.Q16.so.2 = 
/usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2 (0x7f7d415b8000)
  libMagickCore-6.Q16.so.2 = 
/usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2 (0x7f7d410f8000)
  $ 

And this is also why the recipe for reproducing the problem I wrote
includes running Emacs.

I hope this clears it up.


  Best regards,

Adam

-- 
 May the force be... Adam Sjøgren
  ... equal to mass · acceleration  a...@koldfront.dk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771661: machine is completely unusable

2014-12-27 Thread Ben Hutchings

On Sat, 2014-12-27 at 15:13 +0100, Ben Hutchings wrote:
 On Sat, 2014-12-27 at 11:20 +, Toni Mueller wrote:
 [...]
  I am confused because the output is really not that much more verbose
  than the screnshots, but here you are:
  
  
  [   22.224014] INFO: rcu_sched self-detected stall on CPU { 1}  (t=5251 
  jiffies g=-153 c=-154 q=307)
 
 What happened to the first 22 seconds of the log?
 
  [   22.232010] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} 
  (detected by 0, t=5252 jiffies, g=-153, c=-154, q=307)
  [   22.232010] CPU: 0 PID: 122 Comm: systemd-udevd Not tainted 
  3.16.0-0.bpo.4-686-pae #1 Debian 3.16.7-ckt2-1~bpo70+1
  [   22.232010] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  [   22.232010] task: f6c96560 ti: f6cd6000 task.ti: f6cd6000
  [   22.232010] Stack:
  [   22.232010] Call Trace:
 [...]
 
 I don't understand why the stack information is not printed here.
 Please add 'debug' to the kernel command line; that should force it to
 really log everything.

Never mind, I've seen your later message with a complete log and I will
reply to that.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Bug#774014: Segfault after testing connectivity

2014-12-27 Thread Scott Talbert


On Sat, 27 Dec 2014, Vincent Bernat wrote:


of cookies. Increasing the length of the statically allocated buffer
for HTTP headers from 1000 to 1 fix the issue (line 385 of
web.cpp). Tell me if you want a patch.


Thanks!  This has been fixed upstream: 
https://sourceforge.net/p/concordance/bugs/40/


I'll work with Matt to get the patch into Debian ASAP.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774023: unblock: nss/2:3.17.2-1.1

2014-12-27 Thread Matt Kraai

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

Please unblock package nss.

nss/2:3.17.2-1.1 fixes bug #773625, an information leak in NSS (CVE-2014-1569),
using a patch extracted from upstream.

unblock nss/2:3.17.2-1.1

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
diff -Nru nss-3.17.2/debian/changelog nss-3.17.2/debian/changelog
--- nss-3.17.2/debian/changelog	2014-10-17 21:22:21.0 -0700
+++ nss-3.17.2/debian/changelog	2014-12-21 19:46:52.0 -0800
@@ -1,3 +1,10 @@
+nss (2:3.17.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CVE-2014-1569. Closes: #773625.
+
+ -- Matt Kraai kr...@debian.org  Sun, 21 Dec 2014 19:46:52 -0800
+
 nss (2:3.17.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru nss-3.17.2/debian/patches/98_CVE-2014-1569.patch nss-3.17.2/debian/patches/98_CVE-2014-1569.patch
--- nss-3.17.2/debian/patches/98_CVE-2014-1569.patch	1969-12-31 16:00:00.0 -0800
+++ nss-3.17.2/debian/patches/98_CVE-2014-1569.patch	2014-12-21 20:02:10.0 -0800
@@ -0,0 +1,155 @@
+Description: Be more strict on DER length decoding in quickder.c
+Origin: https://hg.mozilla.org/projects/nss/rev/a163e09dc4d5
+Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1064670
+Last-Update: 2014-12-21
+
+# HG changeset patch
+# User J.C. Jones jjo...@mozilla.com
+# Date 1415421927 28800
+# Node ID a163e09dc4d5e90f609f25cf63fae46711b55f73
+# Parent  b6db7a6d2e2c35609450ea8569cc179feffe45e0
+Bug 1064670 - (CVE-2014-1569) ASN.1 DER decoding of lengths is too permissive, allowing undetected smuggling of arbitrary data (r=wtc)
+
+diff --git a/lib/util/quickder.c b/lib/util/quickder.c
+--- nss.orig/nss/lib/util/quickder.c
 nss/nss/lib/util/quickder.c
+@@ -11,65 +11,120 @@
+ #include secasn1.h /* for SEC_ASN1GetSubtemplate */
+ #include secitem.h
+ 
+ /*
+  * simple definite-length ASN.1 decoder
+  */
+ 
+ static unsigned char* definite_length_decoder(const unsigned char *buf,
+-  const unsigned int length,
+-  unsigned int *data_length,
++  const unsigned int buf_length,
++  unsigned int *out_data_length,
+   PRBool includeTag)
+ {
+ unsigned char tag;
+-unsigned int used_length= 0;
+-unsigned int data_len;
++unsigned int used_length = 0;
++unsigned int data_length = 0;
++unsigned char length_field_len = 0;
++unsigned char byte;
++unsigned int i;
+ 
+-if (used_length = length)
++if (used_length = buf_length)
+ {
++/* Tag field was not found! */
+ return NULL;
+ }
+ tag = buf[used_length++];
+ 
+-/* blow out when we come to the end */
+ if (tag == 0)
+ {
++/* End-of-contents octects should not be present in DER because
++   DER doesn't use the indefinite length form. */
+ return NULL;
+ }
+ 
+-if (used_length = length)
++if ((tag  0x1F) == 0x1F)
+ {
++/* High tag number (a tag number  30) is not supported */
+ return NULL;
+ }
+-data_len = buf[used_length++];
+ 
+-if (data_len0x80)
++if (used_length = buf_length)
+ {
+-int  len_count = data_len  0x7f;
++/* Length field was not found! */
++return NULL;
++}
++byte = buf[used_length++];
+ 
+-data_len = 0;
++if (!(byte  0x80))
++{
++/* Short form: The high bit is not set. */
++data_length = byte; /* clarity; we're returning a 32-bit int. */
++}
++else
++{
++/* Long form. Extract the field length */
++length_field_len = byte  0x7F;
++if (length_field_len == 0)
++{
++/* DER doesn't use the indefinite length form. */
++return NULL;
++}
+ 
+-while (len_count--  0)
++if (length_field_len  sizeof(data_length))
+ {
+-if (used_length = length)
++/* We don't support an extended length field  longer than
++   4 bytes (2^32) */
++return NULL;
++}
++
++if (length_field_len  (buf_length - used_length))
++{
++/* Extended length field was not found */
++return NULL;
++}
++
++/* Iterate across the extended length field */
++for (i = 0; i  length_field_len; i++)
++{
++byte = buf[used_length++];
++data_length = (data_length  8) | byte;
++
++if (i == 0)
+ {
+-return NULL;
++

Bug#774024: libglib2.0-dev: glib python macros not enabled - wrong location gdb autoload directory

2014-12-27 Thread Alban Browaeys

Package: libglib2.0-dev
Version: 2.43.2-1
Severity: minor

Dear Maintainer,

current glib/gobject gdb python macros are not in effect as they are at the 
wrong
location :
/usr/share/gdb/auto-load
instead of:
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/

For instance a gdb trace of evolution email MUA shows:
gtk_window_compute_configure_request (window=window@entry=0x7f426631c3e0 
[EShellWindow]
after the move of the existing files to the latter location.


Best regards,
Alban



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

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

Versions of packages libglib2.0-dev depends on:
ii  libc6   2.19-13
ii  libglib2.0-02.43.2-1
ii  libglib2.0-bin  2.43.2-1
ii  libpcre3-dev2:8.35-3.3
ii  pkg-config  0.28-1
pn  python:any  none
ii  zlib1g-dev  1:1.2.8.dfsg-2+b1

libglib2.0-dev recommends no packages.

Versions of packages libglib2.0-dev suggests:
ii  libglib2.0-doc  2.43.2-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750163: postgresql-plproxy: Conflicting declarations of function plproxy_yy_scan_bytes to cause undefined behaviour

2014-12-27 Thread Peter Eisentraut

The flex documentation has

Function: YY_BUFFER_STATE yy_scan_bytes ( const char *bytes, int len)

which is what plproxy abides by.

The actual flex implementation uses yy_size_t, which is really size_t.

Reported upstream as https://sourceforge.net/p/flex/bugs/184/.

Ideally, flex --header-file should be used instead of copying the declaration.

Patch proposed upstream as https://github.com/markokr/plproxy-dev/pull/10.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774025: network-manager: DHCPv6 does not work

2014-12-27 Thread Ralf Jung

Package: network-manager
Version: 0.9.10.0-4
Severity: normal

Dear Maintainer,

DHCPv6 does not work. I set up a connection (using the Plasma frontend) with
* IPv4: Disabled
* IPv6: Automatic (DHCP only)
but when I try to connect, that attempt fails quickly and NM falls back
to another connection. (This is all wireless.)
I am attaching the log output (an excerpt from the systemd journal).

I don't know whether DHCPv6 is working properly here, but my impression
(and my conclusion from the logfiles and the Wireshark logs) is that
NM does not even try to talk with a DHCPv6 server.

I will be at this place for another 3 days, and cannot do any testing
thereafter.

Kind regards,
Ralf

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages network-manager depends on:
ii  adduser3.113+nmu3
ii  dbus   1.8.12-1
ii  init-system-helpers1.22
ii  isc-dhcp-client4.3.1-5
ii  libc6  2.19-13
ii  libdbus-1-31.8.12-1
ii  libdbus-glib-1-2   0.102-1
ii  libgcrypt201.6.2-4+b1
ii  libglib2.0-0   2.42.1-1
ii  libgnutls-deb0-28  3.3.8-5
ii  libgudev-1.0-0 215-8
ii  libmm-glib01.4.0-1
ii  libndp01.4-2
ii  libnewt0.520.52.17-1+b1
ii  libnl-3-2003.2.24-2
ii  libnl-genl-3-200   3.2.24-2
ii  libnl-route-3-200  3.2.24-2
ii  libnm-glib40.9.10.0-4
ii  libnm-util20.9.10.0-4
ii  libpam-systemd 215-8
ii  libpolkit-gobject-1-0  0.105-8
ii  libreadline6   6.3-8+b2
ii  libsoup2.4-1   2.48.0-1
ii  libsystemd0215-8
ii  libteamdctl0   1.12-1
ii  libuuid1   2.25.2-4
ii  lsb-base   4.1+Debian13+nmu1
ii  policykit-10.105-8
ii  udev   215-8
ii  wpasupplicant  2.3-1

Versions of packages network-manager recommends:
ii  crda3.13-1
ii  dnsmasq-base2.72-2
ii  iptables1.4.21-2+b1
ii  iputils-arping  3:20121221-5+b2
ii  modemmanager1.4.0-1
ii  ppp 2.4.6-3

Versions of packages network-manager suggests:
ii  avahi-autoipd  0.6.31-4+b2
pn  libteam-utils  none

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
no-auto-default=10:BF:48:05:C7:F7,
[ifupdown]
managed=false


-- no debconf information
Dec 27 14:06:52 r-schnelltop wpa_supplicant[1306]: wlan0: SME: Trying to 
authenticate with 6c:f3:7f:ec:e9:d0 (SSID='31C3' freq=5540 MHz)
Dec 27 14:06:52 r-schnelltop kernel: wlan0: authenticate with 6c:f3:7f:ec:e9:d0
Dec 27 14:06:52 r-schnelltop wpa_supplicant[1306]: wlan0: Trying to associate 
with 6c:f3:7f:ec:e9:d0 (SSID='31C3' freq=5540 MHz)
Dec 27 14:06:52 r-schnelltop kernel: wlan0: send auth to 6c:f3:7f:ec:e9:d0 (try 
1/3)
Dec 27 14:06:52 r-schnelltop kernel: wlan0: authenticated
Dec 27 14:06:52 r-schnelltop wpa_supplicant[1306]: wlan0: Associated with 
6c:f3:7f:ec:e9:d0
Dec 27 14:06:52 r-schnelltop kernel: wlan0: associate with 6c:f3:7f:ec:e9:d0 
(try 1/3)
Dec 27 14:06:52 r-schnelltop kernel: wlan0: RX AssocResp from 6c:f3:7f:ec:e9:d0 
(capab=0x1011 status=0 aid=19)
Dec 27 14:06:52 r-schnelltop kernel: wlan0: associated
Dec 27 14:06:52 r-schnelltop kernel: cfg80211: Calling CRDA for country: DE
Dec 27 14:06:52 r-schnelltop NetworkManager[968]: info (wlan0): supplicant 
interface state: scanning - authenticating
Dec 27 14:06:52 r-schnelltop NetworkManager[968]: info (wlan0): supplicant 
interface state: authenticating - associated
Dec 27 14:06:52 r-schnelltop wpa_supplicant[1306]: wlan0: 
CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Dec 27 14:06:52 r-schnelltop wpa_supplicant[1306]: wlan0: 
CTRL-EVENT-EAP-STARTED EAP authentication started
Dec 27 14:06:52 r-schnelltop kernel: cfg80211: Regulatory domain changed to 
country: DE
Dec 27 14:06:52 r-schnelltop kernel: cfg80211:  DFS Master region: ETSI
Dec 27 14:06:52 r-schnelltop kernel: cfg80211:   (start_freq - end_freq @ 
bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Dec 27 14:06:52 r-schnelltop kernel: cfg80211:   (240 KHz - 2483500 KHz @ 
4 KHz), (N/A, 2000 mBm), (N/A)
Dec 27 14:06:52 r-schnelltop kernel: cfg80211:   (515 KHz - 525 KHz @ 
8 KHz), (N/A, 2000 mBm), (N/A)
Dec 27 14:06:52 r-schnelltop kernel: cfg80211:   (525 KHz - 535 KHz @ 
8 KHz), (N/A, 2000 mBm), (0 s)
Dec 27 14:06:52 r-schnelltop kernel: cfg80211:   (547 KHz - 5725000 KHz @ 
8 KHz), (N/A, 2698 mBm), (0 s)
Dec 27 14:06:52 r-schnelltop kernel: cfg80211:   (5724 KHz - 6588 KHz @ 
216 KHz), (N/A, 4000 mBm), (N/A)
Dec 27 14:06:52 r-schnelltop wpa_supplicant[1306]:

Bug#773203: unblock: php5/5.6.4+dfsg-0+deb8u1

Hi,

On Sun, 2014-12-21 at 21:06 +0100, Ondřej Surý wrote:
 Control: tags -1 - moreinfo
 
 JFTR php5/5.6.4+dfsg-1 has hit unstable now. I will prepare the usual
 comparison of test suite and debdiff between 5.6.2 and 5.6.4 tomorrow.

Did you have chance to look at that? (I'm more interested in the test
suite diff rather than the debdiff in this case.)

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772855: installation-reports: unable to connect to a wifi network on channel 13

2014-12-27 Thread Lukasz Stelmach

On 27.12.2014 01:43, Ben Hutchings wrote:
 On Sat, 2014-12-13 at 21:51 +0100, Lukasz Stelmach wrote:
 On 11.12.2014 21:57, Ben Hutchings wrote:
 On Thu, 2014-12-11 at 19:28 +0100, Łukasz Stelmach wrote:
 Package: installation-reports
 Severity: important
[...]
 That's strange, apparently the card has been prepared to be for
 Australians, who can use channel 13.

 --8---cut here---start-8---
 Dec 13 18:15:35 main-menu[392]: INFO: Menu item 'ethdetect' selected
 Dec 13 18:15:36 kernel: [  112.707682] cfg80211: Calling CRDA to update 
 world regulatory domain
 Dec 13 18:15:36 kernel: [  112.716130] ath9k :03:00.0: setting latency 
 timer to 64
 Dec 13 18:15:36 kernel: [  112.723098] ath: EEPROM regdomain: 0x21
 Dec 13 18:15:36 kernel: [  112.723101] ath: EEPROM indicates we should 
 expect a direct regpair map
 Dec 13 18:15:36 kernel: [  112.723103] ath: Country alpha2 being used: AU
 Dec 13 18:15:36 kernel: [  112.723104] ath: Regpair used: 0x21
 Dec 13 18:15:36 kernel: [  112.726937] ieee80211 phy0: Selected rate control 
 algorithm 'minstrel_ht'
 Dec 13 18:15:36 kernel: [  112.727445] Registered led device: ath9k-phy0
 Dec 13 18:15:36 kernel: [  112.727450] ieee80211 phy0: Atheros AR9485 Rev:1 
 mem=0xc90011a0, irq=30
 Dec 13 18:15:38 kernel: [  115.279119] ADDRCONF(NETDEV_UP): wlan0: link is 
 not ready
 Dec 13 18:15:40 main-menu[392]: INFO: Menu item 'netcfg' selected
 --8---cut here---end---8---
 
 This driver uses a table of maximum TX power per channel in the wireless
 controller's EEPROM.  It looks like when the 'regpair' value is 0x21
 then it expects to find ETSI rules for the 2.4 GHz band, allowing use of
 channel 13, but it might not.
 
 Does the interface work on channel 13 after installation?  (And assuming
 that you install crda.)

Yes it does.

-- 
Było mi bardzo miło.   Twoje oczy lubią mnie
Łukasz i to mnie zgubi  (c)SNL



signature.asc
Description: OpenPGP digital signature

Bug#773844: wheezy-pu: package apache2/2.2.22-13+deb7u4

Control: tags -1 + pending

On Wed, 2014-12-24 at 10:38 +, Adam D. Barratt wrote:
 Control: tags -1 + confirmed
 
 Hi,
 
  please review the update for apache2 for inclusion into s-p-u. It fixes
  a low-impact security issue and also includes two one-line bug fixes.
  
  The changelog is below, debdiff is attached.

I missed this the first time so it's too late to fix it for this upload,
but:

   The new behavior is to not merge trailers into the headers 
  autmatically.

automatically.

[...]
 Please go ahead, thanks.

For the record, this was uploaded and I've flagged it for acceptance.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#357446: pinfo: UTF8 problems

2014-12-27 Thread Bas Zoetekouw

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Stephan,

 Pinfo still has problems displaying utf-8: - links are highlighted
 in the wrong place - з (CYRILLIC SMALL LETTER ZE) is replaced
 with o, usually with next character - it also results in
 misaligned right edge of text - searched strings are highlighted in
 wrong places

I was looking into this bug, but it seems the gpg package no longer
supplies the Russian info pages.  Could you maybe point me to a
location or a package where I can get them?

Best regards,
Bas.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQIcBAEBCAAGBQJUntMvAAoJENGDpRe/qY3m12sP/0iSsqOqVKI/OzxhPSbbL/J/
yvcvMw9qhcEdKga9yVsLt4s34KYV+V3JVV63njJheHN5oV/CLLyc0iFnVeXsxf3n
YE9zUmWjL57ULD4R7Ty26+RacyyC54p+Aebyic0FTyhZSjBDg81oqOXdg2NwEpp2
I+q2NR4GZAgRSNzsqg91IJwJcIk/30BpFMuWrCC8Txvw943z5rXClh0+zDVvTkwY
x2gsTrmO011xqbVcoE+qeiyLVh/vOQNEzII/1E9za6Toeu74KPb6atQp2sf4A8SM
4LWVPdYfkU59NE8aBW6sf3pNmehDfpgMIK2QalbIodha59QOHRDAgzMyo1rB9zkG
bL2/UcVwnrl5tXXp24wJ1r+jBN9SnweOdp77UvGCWd++HEE2sG9QmSRcD9Ci9vdn
9UGCtLQffnu+ZJ3Hn2xjIKNNiyECUnB8/4J821chE0MOqoxLPx3EuGiJEa5ugJZ4
bmZn6Cvz205tmmRrMY5Z9s6ik7cYfqJsqyxg0hL+iXsbCwCfVqBdoKyTHYGWRxhH
fJCXmK/bRZA+egvV7QDndQDzDp1bSzfkdF8oWTdF9iqpGI2dPIbw3RZIZ6dfL2tc
7F7dAOTc+2AnIC873F/6fZ1c/FFYyCB4jKHsCW4xNIykMWt1wSeTBllxFKANT0oJ
D5Z+s1tZlVOP+GUZx/rn
=FfwM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741573: Two menu systems

2014-12-27 Thread Wouter Verhelst

On Mon, 22 Dec 2014 14:29:44 + Ian Jackson 
ijack...@chiark.greenend.org.uk wrote:
 The traditional Debian menu system (mostly done by Bill Alombert) has
 been providing menu entries for bc and dc and everything for years.
 That is what its users expect.  It is what users like Matthew Vernon
 want:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#20
 
 What you are suggesting above is that the Debian menu will simply be
 abolished.

This seems correct.

 No-one will be allowed[1] to provide a comprehensive menu in Debian.

This doesn't.

The trad menu system and the desktop menu system are both, in essence,
just a bunch of metadata. What's represented in that metadata is how do
you start this particular bit of software. To that extent, they are the
same.

The actual *contents* of the trad menu system and the desktop menu
system is vastly different. I suspect that the opposition to losing the
trad menu system is not so much about the metadata *format* as it is
about the *contents* of those menu systems; about the actual menus that
result from interpreting the metadata.

But I don't see why that would need to be a problem, or indeed be part
of this question.

There is no reason why we wouldn't, theoretically, be able to build a
menu system that had a semantically similar (although perhaps differing
in minor details, such as categories etc) contents as does the trad
menu system, but using desktop metadata rather than trad metadata.

There is no reason why moving to desktop files as supported menu
system must imply losing most or all of the contents that the trad
menu currently contains. It could, yes, and maybe it would make sense
if some of the more... unusual menu entries (such as those for bash
or python) were removed from the menu system. However, that is a
wholly different question as to the question of which metadata format we
decide to go with, long-term.

I submit that the TC, for the purpose of answering this question before
it, should at first simply decide on a preferred metadata format. The
contents of the resulting menus is something they can then decide on as
a separate question (or ignore altogether if they decide it is not
appropriate for them to make that decision).

I will add that the debian menu is an all-or-nothing approach; TTBOMK it
is not possible to create an entry in the Debian menu saying something
along the lines of this should not be shown by default or this should
not be shown by default in environment X. This might be one reason for
the choice of some of our DE maintainers to decide not to show the
Debian menu anymore.

The same is not true for the desktop metadata format.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772687: fonts-droid: fallback font is installed too early to fontconfig

2014-12-27 Thread Hideki Yamane

control: severity -1 important

Hi,

On Wed, 10 Dec 2014 13:49:54 +0900
Norbert Preining prein...@logic.at wrote:
 currently it seems that the fallback font is installed as
   65-droid-sans-fallback.conf
 which overrides 65-nonlatin.conf as well as any other selection
 done by other groups.
 
 The effect is that Japanese characters are incorrectly displayed
 wit Chinese characters.
 
 As far as I understand, the fallback should come last.

 With d-i beta2, fonts-droid package is pulled by default into Japanese
 desktop environment, and it breaks proper font selection and desktop 
 looks. So, I'll up it to severity: important.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774006: RFP: libinline-python-perl -- write Perl subs and classes in Python

2014-12-27 Thread gregor herrmann

On Fri, 26 Dec 2014 22:27:10 -0800, tony mancill wrote:

 * Package name: libinline-python-perl
   Version : 0.46
   Upstream Author : Stefan Seifert n...@cpan.org
 * URL : https://metacpan.org/release/Inline-Python
 * License : The Perl 5 License (Artistic 1  GPL 1)
   Programming Lang: Perl
   Description : write Perl subs and classes in Python

Uploaded to NEW, git repo in pkg-perl.

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beatles: Wild Honey Pie


signature.asc
Description: Digital Signature

Bug#774026: uwsgi-plugin-jvm-openjdk-7: bogus RPATH


Package: uwsgi-plugin-jvm-openjdk-7
Version: 2.0.7-1

/usr/lib/uwsgi/plugins/jvm_openjdk7_plugin.so has the following RPATH:
/usr/lib/jvm/java-7-openjdk-i386/jre/lib/i386/server

The quotation marks are part of the path, so the path is relative, not 
absolute! This is certainly not what you wanted.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774027: uwsgi-plugin-jwsgi-openjdk-7: bogus RPATH


Package: uwsgi-plugin-jwsgi-openjdk-7
Version: 2.0.7-1

/usr/lib/uwsgi/plugins/jwsgi_openjdk7_plugin.so has the following RPATH:
/usr/lib/jvm/java-7-openjdk-i386/jre/lib/i386/server

The quotation marks are part of the path, so the path is relative, not 
absolute! This is certainly not what you wanted.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774024: libglib2.0-dev: glib python macros not enabled - wrong location gdb autoload directory

Le Sat, 27 Dec 2014 15:55:39 +0100,
Alban Browaeys pra...@yahoo.com a écrit :

 Dear Maintainer,

Hello,

 current glib/gobject gdb python macros are not in effect as they are
 at the wrong location :
 /usr/share/gdb/auto-load
 instead of:
 /usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/

If I'm not wrong, libglib2.0-dev ships 2 gdb auto-load files:

libglib-2.0.so.0.4200.1-gdb.py and libgobject-2.0.so.0.4200.1-gdb.py
that refer to libraries shipped in /lib (glib) and /usr/lib (gobject).

So I guess that the new paths should be the following then:

/usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.1-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1-gdb.py

Cheers,

Laurent Bigonville


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772921: grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2

2014-12-27 Thread Timo Jyrinki

18.12.2014, 10:50, Ian Campbell kirjoitti:
11.12.2014, 21:59, Ian Campbell kirjoitti:
Please send the updated file to me, or submit it as a wishlist bug
against grub2.

Attached is the updated fi.po.

Thanks again.

I just wanted to check that you had seen the followup CFT, which I'm
afraid will have fuzzied the new translation:
...
It has been brought to my attention that the phrase EFI removable path in
the
previous English version is confusing and wrong and should really be EFI
removable media path. Therefore I am sending out an updated po file (see
attached) with this fixed.

I'm afraid this will have marked any existing translations as fuzzy.

Updated fi.po attached. Removed the fuzzies and adjusted the translation
a bit. I'm aware the upload was already done, so maybe for the next one.
As the translation is otherwise done, this is not hugely important.

Thank you for the translation enablement work!

-Timo

# Esko ArajÃ¤rvi e...@iki.fi, 2009, 2010.
# Timo Jyrinki timo.jyri...@iki.fi, 2012, 2014.
msgid
msgstr
Project-Id-Version: grub2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-27 18:53+0200\n
Last-Translator: Timo Jyrinki timo.jyri...@iki.fi\n
Language-Team: Finnish debian-l10n-finn...@lists.debian.org\n
Language: fi\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Poedit-Language: Finnish\n
X-Poedit-Country: FINLAND\n
X-Generator: Lokalize 1.0\n
Plural-Forms: nplurals=2; plural=(n != 1);\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Ladataanko ketjutettuna tiedostosta menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr
GRUBin pÃ¤ivityskomentosarjat ovat lÃ¶ytÃ¤neet vanhoja GRUB-asetuksia
tiedostosta /boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
In order to replace the Legacy version of GRUB in your system, it is
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image
from your existing GRUB Legacy setup. This step can be automatically
performed now.
msgstr
JÃ¤rjestelmÃ¤ssÃ¤ olevan vanhan GRUB-version korvaamiseksi on suositeltavaa
muokata tiedostoa /boot/grub/menu.lst siten, ettÃ¤ GRUB 2 ladataan olemassa
olevista vanhoista GRUB-asetuksista. TÃ¤mÃ¤ voidaan tehdÃ¤ automaattisesti nyt.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
On suositeltavaa, ettÃ¤ hyvÃ¤ksyt GRUB 2:n ketjutetun lataamisen tiedostosta
menu.lst ja varmistat uusien GRUB 2 -asetusten toimivuuden ennen kuin
asennat ne pÃ¤Ã¤kÃ¤ynnistyslohkoon (MBR).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command as root:
msgstr
Riippumatta valinnasta vanha MBR voidaan korvata GRUB 2:lla myÃ¶hemmin
suorittamalla seuraava komento pÃ¤Ã¤kÃ¤yttÃ¤jÃ¤nÃ¤:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr Laitteet joille GRUB asennetaan:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
The grub-pc package is being upgraded. This menu allows you to select which
devices you'd like grub-install to be automatically run for, if any.
msgstr
grub-pc-pakettia pÃ¤ivitetÃ¤Ã¤n. TÃ¤stÃ¤ valikosta voit valita, mille laitteille
grub-install suoritetaan automaattisesti.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
Running grub-install automatically is recommended in most situations, to
prevent the installed GRUB core image from getting out of sync with GRUB
modules or grub.cfg.
msgstr
grub-install:n suorittaminen automaattisesti on suositeltavaa useimmissa
tilanteissa, jotta asennettu GRUB-ydin ei tulisi epÃ¤yhteensopivaksi GRUB-
moduulien tai grub.cfg:n kanssa.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
If you're unsure which drive is designated as boot drive by your BIOS, it is
often a good idea to install GRUB to all of them.
msgstr
Jos et ole varma, mikÃ¤ asema on mÃ¤Ã¤ritelty kÃ¤ynnistysasemaksi koneen BIOS-
asetuksissa, on usein hyvÃ¤ ajatus asentaa GRUB kaikille asemille.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
Note: it is possible to install GRUB to partition boot records as well, and
some appropriate partitions are offered here. However, this forces GRUB to
use the blocklist

Bug#765639: wheezy-pu: openssl new upstream version

2014-12-27 Thread Kurt Roeckx

On Thu, Oct 16, 2014 at 10:12:16PM +0200, Kurt Roeckx wrote:
 I would really like to upload new upstream openssl versions from
 the 1.0.1-stable branch to wheezy.

Could someone please say something about this request?


Kurt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774028: fuse: Spews out screen worth of ERRORs during upgrade

2014-12-27 Thread Niels Thykier

Package: fuse
Version: 2.9.3-15+b1
Severity: important

Hi,

In an automated upgrade on jenkins.d.n[1], I noticed the following
error(s) from what appears to be the fuse postinst script:


Setting up libfuse2:amd64 (2.9.3-15+b1) ...
Setting up fuse (2.9.3-15+b1) ...
Installing new version of config file /etc/fuse.conf ...
libkmod: ERROR ../libkmod/libkmod-module.c:1903 kmod_module_get_holders: could 
not open '/sys/module/dccp_ipv4/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1903 kmod_module_get_holders: could 
not open '/sys/module/dccp/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1903 kmod_module_get_holders: could 
not open '/sys/module/fuse/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1903 kmod_module_get_holders: could 
not open '/sys/module/nls_utf8/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1903 kmod_module_get_holders: could 
not open '/sys/module/isofs/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1903 kmod_module_get_holders: could 
not open '/sys/module/xt_CHECKSUM/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1903 kmod_module_get_holders: could 
not open '/sys/module/ipt_MASQUERADE/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1903 kmod_module_get_holders: could 
not open '/sys/module/aufs/holders': No such file or directory
[...]


These errors continues quite a bit.  It would be vastly more pleasent
if our upgrade from Wheezy did not fill displays and log files with
errors.  :)

If you can provide a reasonable patch for this, I would be delighted
to have it included in the Jessie release.

Thanks,
~Niels

[1] 
https://jenkins.debian.net/job/chroot-installation_wheezy_install_full_desktop_upgrade_to_jessie/515/consoleFull


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774029: unblock: screen-message/0.23-1

2014-12-27 Thread Joachim Breitner

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

the latest upload of screen-message contains a fix for a problem that
appeared due to some unidentified dependency change a few months ago,
likely gtk. The problem was communicated to me directly and fixed right
away, so there is no bug report for this.

The user pointed out that the problem is a serious impediment to proper
use of sm, hence this unblock request, despite this being technically a
new upstream version (with no other change than this fix).

The problem at hand is that screen-message will update the screen only
every other key press. Which indeed defies it purpose quite a bit.

Thanks for considering

unblock screen-message/0.23-1

debdiff attached.

Joachim

- -- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 3.16.0-4-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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlSe6QwACgkQ9ijrk0dDIGxMqgCfaZZsTqlFE926G3jx3/wf+xCx
mxoAnik5BR9iTQDEvOV/9WaWZxe9O1xy
=svrX
-END PGP SIGNATURE-
diff -Nru screen-message-0.22.2/aclocal.m4 screen-message-0.23/aclocal.m4
--- screen-message-0.22.2/aclocal.m4	2014-09-30 15:44:54.0 +0200
+++ screen-message-0.23/aclocal.m4	2014-12-23 19:35:35.0 +0100
@@ -318,10 +318,9 @@
 # configured tree to be moved without reconfiguration.
 
 AC_DEFUN([AM_AUX_DIR_EXPAND],
-[dnl Rely on autoconf to set up CDPATH properly.
-AC_PREREQ([2.50])dnl
-# expand $ac_aux_dir to an absolute path
-am_aux_dir=`cd $ac_aux_dir  pwd`
+[AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
+# Expand $ac_aux_dir to an absolute path.
+am_aux_dir=`cd $ac_aux_dir  pwd`
 ])
 
 # AM_CONDITIONAL-*- Autoconf -*-
diff -Nru screen-message-0.22.2/configure screen-message-0.23/configure
--- screen-message-0.22.2/configure	2014-09-30 15:44:55.0 +0200
+++ screen-message-0.23/configure	2014-12-23 19:35:35.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for screen-message 0.22.2.
+# Generated by GNU Autoconf 2.69 for screen-message 0.23.
 #
 # Report bugs to m...@joachim-breitner.de.
 #
@@ -580,8 +580,8 @@
 # Identity of this package.
 PACKAGE_NAME='screen-message'
 PACKAGE_TARNAME='screen-message'
-PACKAGE_VERSION='0.22.2'
-PACKAGE_STRING='screen-message 0.22.2'
+PACKAGE_VERSION='0.23'
+PACKAGE_STRING='screen-message 0.23'
 PACKAGE_BUGREPORT='m...@joachim-breitner.de'
 PACKAGE_URL=''
 
@@ -1249,7 +1249,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat _ACEOF
-\`configure' configures screen-message 0.22.2 to adapt to many kinds of systems.
+\`configure' configures screen-message 0.23 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1315,7 +1315,7 @@
 
 if test -n $ac_init_help; then
   case $ac_init_help in
- short | recursive ) echo Configuration of screen-message 0.22.2:;;
+ short | recursive ) echo Configuration of screen-message 0.23:;;
esac
   cat \_ACEOF
 
@@ -1421,7 +1421,7 @@
 test -n $ac_init_help  exit $ac_status
 if $ac_init_version; then
   cat \_ACEOF
-screen-message configure 0.22.2
+screen-message configure 0.23
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1555,7 +1555,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by screen-message $as_me 0.22.2, which was
+It was created by screen-message $as_me 0.23, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -2105,8 +2105,8 @@
 ac_script='s/[\\$]//g;s/;s,x,x,$//'
 program_transform_name=`$as_echo $program_transform_name | sed $ac_script`
 
-# expand $ac_aux_dir to an absolute path
-am_aux_dir=`cd $ac_aux_dir  pwd`
+# Expand $ac_aux_dir to an absolute path.
+am_aux_dir=`cd $ac_aux_dir  pwd`
 
 if test x${MISSING+set} != xset; then
   case $am_aux_dir in
@@ -2419,7 +2419,7 @@
 
 # Define the identity of the package.
  PACKAGE='screen-message'
- VERSION='0.22.2'
+ VERSION='0.23'
 
 
 cat confdefs.h _ACEOF
@@ -5047,7 +5047,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log=
-This file was extended by screen-message $as_me 0.22.2, which was
+This file was extended by screen-message $as_me 0.23, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -5113,7 +5113,7 @@
 cat

Bug#744753: anacron: Anacron not triggered when system resumes under systemd

2014-12-27 Thread Peter Eisentraut

I don't know much about systemd, so I can't be of much help with this.

If anyone wants to take responsibility for a solution, please go ahead.
(Also consider addressing #771393 at the same time.)

An alternative would be to remove systemd support from the package for
the release and rely on the plain old sysvinit setup.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774029: unblock: screen-message/0.23-1

Control: tags -1 + moreinfo

On Sat, 2014-12-27 at 18:14 +0100, Joachim Breitner wrote:
 the latest upload of screen-message contains a fix for a problem that
 appeared due to some unidentified dependency change a few months ago,
 likely gtk. The problem was communicated to me directly and fixed right
 away, so there is no bug report for this.

It doesn't look like 0.23 is in the archive yet?

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773343: request-tracker4: fails to upgrade from 'wheezy' if rt4-extension-assettracker is installed

2014-12-27 Thread Niko Tyni

(Chiming in, but please note that I don't consider myself much of an RT
maintainer anymore even if I'm still listed in Uploaders.)

On Thu, Dec 25, 2014 at 02:35:42PM +0900, Satoru KURASHIKI wrote:

 a. implement some migration from assettracker to RTx::Assets (but
 refered as too late in #748737)
 b. patch RT's db migration script to allow assettracker's modification
 c. purge assettracker with its data dump and recover RTDB before upgrading RT
 d. skip RT upgrade if assettracker is installed
 e. etc, etc.

c) seems rather destructive, I don't think we can/should do that
automatically. d) would be OK but I'm not sure if dbconfig-common can
be told to do that. However, b) actually seems attainable. See below.

The problem seems to be that the RTx::AssetTracker setup accidentally
inserts two almost identical sets of system role groups, and those
violate uniqueness constraints during the upgrade. From a database dump
diff after installing rt4-extension-assettracker on wheezy:

+INSERT INTO Groups 
VALUES(22,NULL,NULL,'RTx::AssetTracker::System-Role','Admin',0,1,'2014-12-26 
15:05:46',1,'2014-12-26 15:05:46');
+INSERT INTO Groups 
VALUES(23,NULL,NULL,'RTx::AssetTracker::System-Role','Owner',0,1,'2014-12-26 
15:05:46',1,'2014-12-26 15:05:46');
+INSERT INTO Groups VALUES(24,'','SystemRolegroup for internal 
use','RTx::AssetTracker::System-Role','Owner',0,1,'2014-12-26 
15:05:46',1,'2014-12-26 15:05:46');
+INSERT INTO Groups VALUES(25,'','Pseudogroup for internal 
use','RTx::AssetTracker::System-Role','Admin',0,1,'2014-12-26 
15:05:46',1,'2014-12-26 15:05:46');

The database initialization code installed as
 /usr/share/request-tracker4/plugins/RTx-AssetTracker/etc/initialdata
explicitly inserts the latter ones, but the 'use RTx::AssetTracker'
declaration gets run before that. This calls
 RTx::AssetTracker::Type-ConfigureRoles()
which ends up creating the first two groups around
 lib/RTx/AssetTracker/Type_Overlay.pm:153
because they don't exist yet.

The smallest database change I can think of to fix the problem is
something like
 UPDATE Groups set Instance=1 WHERE Domain='RTx::AssetTracker::System-Role' AND 
Description IS Null;
which could presumably be dropped into the request-tracker4 dbconfig-common
upgrade directories. I'd expect it to complete as a no-op on systems
without RTx::AssetTracker installed.

Disclaimer: I don't really know what the 'Instance' field is used for,
and the above change could well break RTx::AssetTracker or even RT
itself. I've only tested that it allows the request-tracker4 upgrade to
complete successfully with the (default) SQLite backend.  Testing with
Pg/mysql would be good too, as the 'Description IS Null' part feels a
bit fragile to me.

On a related note, does the wheezy RTx::AssetTracker even work with the
jessie RT? If it doesn't, a Breaks: entry would probably be warranted.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774029: unblock: screen-message/0.23-1

2014-12-27 Thread Joachim Breitner

Hi,

Am Samstag, den 27.12.2014, 17:21 + schrieb Adam D. Barratt:
 Control: tags -1 + moreinfo
 
 On Sat, 2014-12-27 at 18:14 +0100, Joachim Breitner wrote:
  the latest upload of screen-message contains a fix for a problem that
  appeared due to some unidentified dependency change a few months ago,
  likely gtk. The problem was communicated to me directly and fixed right
  away, so there is no bug report for this.
 
 It doesn't look like 0.23 is in the archive yet?

indeed, but how did that happen? I have a signed changes and an upload
log here, from 2014-12-23 (attached to prove myself I’m not crazy), but
I don’t find mails from the archive bots about it.

@ftp-master: Can you tell what I did wrong?

Just dput’ed it again.

Greetings,
Joachim


-- 
Joachim nomeata Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 23 Dec 2014 19:41:09 +0100
Source: screen-message
Binary: sm
Architecture: source amd64
Version: 0.23-1
Distribution: unstable
Urgency: medium
Maintainer: Joachim Breitner nome...@debian.org
Changed-By: Joachim Breitner nome...@debian.org
Description:
 sm - Displays a short text fullscreen
Changes:
 screen-message (0.23-1) unstable; urgency=medium
 .
   * New upstream release:
 .
 Disable temporary disabling of anti-aliasing
 .
 It seems to have stopped working with recent versions of gtk3, and
 furthermore causes every second keypress to be ignored.
Checksums-Sha1:
 3aadf353ac39fd09b3518610088afc4d81335aa3 1252 screen-message_0.23-1.dsc
 7b2a0dc82734862e58011f92f7ce85c5363223ed 347123 screen-message_0.23.orig.tar.gz
 ae887e25402f4307350d77519355e31e18492d1f 3256 
screen-message_0.23-1.debian.tar.xz
 807b870335aff86e89ab0af88173a796ecd5d43f 15262 sm_0.23-1_amd64.deb
Checksums-Sha256:
 ed37ed30a581c124d0b35221279df811785f5e6165dd3093c9aa14b187dffc95 1252 
screen-message_0.23-1.dsc
 6a34fca5a4816f80504a872221a44ff982f7854eb2d3529369e77722b4a4f420 347123 
screen-message_0.23.orig.tar.gz
 dd924cf1dfd9d8c07c994b1f67e3468f3aa0efa392bfa709db8d37de1e3b0b57 3256 
screen-message_0.23-1.debian.tar.xz
 fc145476bd454a134c7270c3025f647abf3e0ec019440ed7d8932217525b12e0 15262 
sm_0.23-1_amd64.deb
Files:
 1791b7b8aa5300b43d5a2a339e63c9e4 1252 games optional screen-message_0.23-1.dsc
 6e9793e40ab4f266840fea7064e93891 347123 games optional 
screen-message_0.23.orig.tar.gz
 6f7b3239f0216419c74dfca3cdc6c609 3256 games optional 
screen-message_0.23-1.debian.tar.xz
 ac2727db1fc9ccbfa59fb10806257318 15262 games optional sm_0.23-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlSZuy8ACgkQ9ijrk0dDIGzAkACgyy0EHHAqBnB8HYY+tZ6WNaCN
7HEAoNG683cNB2TKMrnzclR/IZimmWwe
=0U2b
-END PGP SIGNATURE-
2014-12-23 19:57:55,201 - dput[29306]: uploader.invoke_dput - Uploading 
screen-message using ftp to ftp-master (host: ftp.upload.debian.org; directory: 
/pub/UploadQueue/)
2014-12-23 19:57:55,201 - dput[29306]: hook.run_hook - running 
allowed-distribution: check whether a local profile permits uploads to the 
target distribution
2014-12-23 19:57:55,204 - dput[29306]: hook.run_hook - running 
protected-distribution: warn before uploading to distributions where a special 
policy applies
2014-12-23 19:57:55,205 - dput[29306]: hook.run_hook - running checksum: verify 
checksums before uploading
2014-12-23 19:57:55,208 - dput[29306]: hook.run_hook - running suite-mismatch: 
check the target distribution for common errors
2014-12-23 19:57:55,210 - dput[29306]: hook.run_hook - running check-debs: 
makes sure the upload contains a binary package
2014-12-23 19:57:55,211 - dput[29306]: hook.run_hook - running gpg: check GnuPG 
signatures before the upload
2014-12-23 19:57:56,517 - dput[29306]: uploader.invoke_dput - Uploading 
screen-message_0.23-1.dsc
2014-12-23 19:57:57,254 - dput[29306]: uploader.invoke_dput - Uploading 
screen-message_0.23.orig.tar.gz
2014-12-23 19:58:01,691 - dput[29306]: uploader.invoke_dput - Uploading 
screen-message_0.23-1.debian.tar.xz
2014-12-23 19:58:02,452 - dput[29306]: uploader.invoke_dput - Uploading 
sm_0.23-1_amd64.deb
2014-12-23 19:58:03,337 - dput[29306]: uploader.invoke_dput - Uploading 
screen-message_0.23-1_amd64.changes


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

Bug#773343: request-tracker4: fails to upgrade from 'wheezy' if rt4-extension-assettracker is installed

2014-12-27 Thread gregor herrmann

On Sat, 27 Dec 2014 19:27:03 +0200, Niko Tyni wrote:

 On a related note, does the wheezy RTx::AssetTracker even work with the
 jessie RT? If it doesn't, a Breaks: entry would probably be warranted.

According to #748737 it doesn't, that's why it's not in testing :)
So I think a Breaks is necessary in any case.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: The Sandpipers: Guantanamera


signature.asc
Description: Digital Signature

Bug#774029: unblock: screen-message/0.23-1

On Sat, 2014-12-27 at 18:28 +0100, Joachim Breitner wrote:
 Hi,
 
 Am Samstag, den 27.12.2014, 17:21 + schrieb Adam D. Barratt:
  Control: tags -1 + moreinfo
  
  On Sat, 2014-12-27 at 18:14 +0100, Joachim Breitner wrote:
   the latest upload of screen-message contains a fix for a problem that
   appeared due to some unidentified dependency change a few months ago,
   likely gtk. The problem was communicated to me directly and fixed right
   away, so there is no bug report for this.
  
  It doesn't look like 0.23 is in the archive yet?
 
 indeed, but how did that happen? I have a signed changes and an upload
 log here, from 2014-12-23 (attached to prove myself I’m not crazy), but
 I don’t find mails from the archive bots about it.
 
 @ftp-master: Can you tell what I did wrong?

Not ftp-master, but the queued log says:

Dec 23 18:58:25 processing /screen-message_0.23-1_amd64.changes
Dec 23 18:58:25 GnuPG signature check failed on
screen-message_0.23-1_amd64.changes
Dec 23 18:58:25 /screen-message_0.23-1_amd64.changes has bad PGP/GnuPG
signature!
Dec 23 18:58:25 Removing /screen-message_0.23-1_amd64.changes, but
keeping its associated files for now.
Dec 24 19:02:46 Deleted stray file /screen-message_0.23.orig.tar.gz
Dec 24 19:02:46 Deleted stray file /screen-message_0.23-1.dsc
Dec 24 19:02:46 Deleted stray file /screen-message_0.23-1.debian.tar.xz

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756988: desktop-base: please provide a background for GDM 3 and its screen lock mode

2014-12-27 Thread Martin-Éric Racine

Package: desktop-base
Followup-For: Bug #756988

While 8.0.1 in principle introduced new background images for GDM (Thanks!), 
GDM still shows its default gray background.

Running 'gksudo -u Debian-gdm gnome-tweak-tool' confirms that lines.xml and 
lines-lockscreen.xml are correctly configured in the dconf keys, so I'm 
guessing that the problem is somewhere else e.g. hard-coded paths in the gdm3 
package.

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (1001, 'testing'), (1001, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages desktop-base depends on:
ii  dpkg 1.17.22
ii  librsvg2-common  2.40.5-1

desktop-base recommends no packages.

Versions of packages desktop-base suggests:
pn  gnome | kde-standard | xfce4 | wmaker  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/debian-bugs-dist

Bug#774029: unblock: screen-message/0.23-1

2014-12-27 Thread Joachim Breitner

Hi,

Am Samstag, den 27.12.2014, 17:32 + schrieb Adam D. Barratt:
 Not ftp-master, but the queued log says:
 
 Dec 23 18:58:25 processing /screen-message_0.23-1_amd64.changes
 Dec 23 18:58:25 GnuPG signature check failed on
 screen-message_0.23-1_amd64.changes
 Dec 23 18:58:25 /screen-message_0.23-1_amd64.changes has bad PGP/GnuPG
 signature!
 Dec 23 18:58:25 Removing /screen-message_0.23-1_amd64.changes, but
 keeping its associated files for now.
 Dec 24 19:02:46 Deleted stray file /screen-message_0.23.orig.tar.gz
 Dec 24 19:02:46 Deleted stray file /screen-message_0.23-1.dsc
 Dec 24 19:02:46 Deleted stray file /screen-message_0.23-1.debian.tar.xz

right, for some reason debsign keeps using my old key, and the the
default-key F0FBF51F, so unless I specify -k, this happens.

Resigned, but upload will have to wait until the current one is removed.

Too bad there is not mail sent out in this case (but it makes sense).

Feel free to unblock nevertheless already :-)

Greetings,
Joachim

-- 
Joachim nomeata Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Bug#773256: pre-approval: unblock: dpkg/1.17.23

2014-12-27 Thread Niels Thykier

On 2014-12-23 04:36, Guillem Jover wrote:
 Hi!
 

Hi,

 On Sun, 2014-12-21 at 09:57:51 +0100, Niels Thykier wrote:
   It possibly still is since the version that introduced the trigger
 checks.  I hope we can have it resolved shortly.
 
 Yeah, I'm planning to upload tomorrow, sorry about the delay, was not
 feeling quite well the past couple of days.
 

I hope you are feeling better now. :)

TL;DR: Please upload dpkg/1.17.23 with the proposed fix for #771730 at
your earliest convenience - by the looks of it, might fix one or two of
our upgrade tests on jenkins.d.n.

 [...]

 Indeed I missed those.  For reference, pypy got fixed and gxine, icecc
 and mcollective will get auto-removed eventually.  My previous remark
 for gxine plus icecc applies equally to mcollective (and pypy, in case
 migration is stalled) as well.
   This leaves auctex as the only remaining blocker auctex.
 
 In the meantime mcollective also got fixed, which leaves auctex, gxine,
 icecc and wordpress. The latter has a fixed package sitting in NEW
 (but I'm not sure it will be accepted and allowed to migrate?).
 

Thanks for the update.  I will have a look at poking the remaining packages.

 I've added  versioned Breaks for the packages with fixed versions,
 and = for the ones with unfixed ones against the version in testing
 (as for auctex it differs against unstable).
 

Ok.

 [...]
 
 @deity/@dpkg: Right now, I am less concerned with whose fault it is
 and vastly more concerned with getting a functional upgrade path.
   If the correct fix is in APT and it can be provided in a reviewable
 diff in a reasonable time frame, I will happily take that.  Otherwise,
 the fix needs to be in dpkg (despite being wrong or a revert).  At
 this point in the freeze, we do not have the luxury of finding perfection.
 
 Sorry, my point was that I don't think we know exactly what lead
 to the dbus issue, which apt versions are affected, or if this is
 actually something that showed up due to the trigger changes, dbus
 maintscripts errors and if it was a latent issue that could as well
 show up with a system crash leaving dpkg in a broken state, etc.
 
 As I've mentioend before I don't mind at all adding a workaround in
 dpkg if that provides a smooth upgrade path, but I'd like to do that
 understanding what it's working around, and that it actually fixes
 the issue, and not just blindly.
 

Noted.  Do we (still?) have a (reliable) way of reproducing the dbus
trigger issue?

 The main issue for me is that besides this trigger issue, we also got
 the entire init system replacement on upgrades.  I fear this is
 uncharted territories right now because everybody is (mostly) stuck
 behind these trigger issues.
 
 While I think trigger cycles (be them real or bogusly detected as
 the ones in 1.17.22) should be RC, they are actually recoverable
 upgrade errors, as package involved in trigger cycles get reset into
 half-configured, and their pending triggers reset. Which means that
 a subsequent apt invocation should be able to continue from where it
 was left off. So I don't think this has gotten people stuck on upgrade
 problems (at least with dpkg = 1.17.22).
 

It is not about whether they are recoverable.  Most people do not
upgrade systems if they are aware of known unresolved upgrade issues.

The sooner we can say All of the dpkg and APT issues are now fixed; go
forth and test upgrade into Jessie, the sooner I get to the next level
of issues.

 The dbus problem seemed to be actually more severe, because although
 «dpkg --configure --pending» seemed to be able to recover from the
 situation, apt did not and got stuck there w/o being able to continue,
 at least from the logs and comments in the bug reports, but not many
 people have reported such issue so…
 

Noted.

 I also don't
 know what's the stance on requiring specific packaging tools to be
 upgraded first? Which might mean that if the issue is still there it
 could be fixed in apt proper.

 (@deity: You may want to have a look at this as well)

 As I recall, it is not a requirement - but I believe we can recommend it
 in the release-notes.  [...]
 
 If it's just a recommendation then I'm not sure that would be
 satisfactory as we cannot rely on it.

Indeed and even then, some people might not read the release notes until
after.

 In any case for apt-based (or
 cupt) frontends the important thing is to get the frontends upgraded
 first, because dpkg ends up being invoked many times, and the new
 version will be picked up once it gets upgraded. Also frontends seem
 to favor Essential packages so they will get upgraded very early and
 on its own dpkg run. But if something got to be added, then I guess
 just requiring to upgrade apt or cupt would be enough.
 
 Thanks,
 Guillem
 
 

If we add something, we might as well add dpkg as well. :)

[From a different mail than the one I am replying to]
 On Tue, 2014-12-23 at 04:36:07 +0100, Guillem Jover wrote:
 On Sun, 2014-12-21 at 09:57:51 +0100, Niels Thykier

Bug#773343: request-tracker4: fails to upgrade from 'wheezy' if rt4-extension-assettracker is installed

2014-12-27 Thread Niko Tyni

On Sat, Dec 27, 2014 at 06:35:20PM +0100, gregor herrmann wrote:
 On Sat, 27 Dec 2014 19:27:03 +0200, Niko Tyni wrote:
 
  On a related note, does the wheezy RTx::AssetTracker even work with the
  jessie RT? If it doesn't, a Breaks: entry would probably be warranted.
 
 According to #748737 it doesn't, that's why it's not in testing :)
 So I think a Breaks is necessary in any case.

Ah, thanks. #748737 itself really looks like a duplicate of this same
issue with uniqueness constraint violations, but the linked upstream
bug at https://github.com/AssetTracker/rt-extension-assettracker/issues/62
suggests there are real compatibility issues too.

So agreed, a Breaks: seems to be needed.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774029: unblock: screen-message/0.23-1

2014-12-27 Thread Ansgar Burchardt

Hi,

Joachim Breitner nome...@debian.org writes:
 Am Samstag, den 27.12.2014, 17:21 + schrieb Adam D. Barratt:
 It doesn't look like 0.23 is in the archive yet?

 indeed, but how did that happen? I have a signed changes and an upload
 log here, from 2014-12-23 (attached to prove myself I’m not crazy), but
 I don’t find mails from the archive bots about it.

 @ftp-master: Can you tell what I did wrong?

The .changes was signed with your old key:

  gpg: Signature made Tue Dec 23 19:57:51 2014 CET
  gpg:using DSA key 0xF628EB934743206C

Ansgar


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756988: desktop-base: please provide a background for GDM 3 and its screen lock mode

2014-12-27 Thread Vincent Blut

Le sam. 27 déc. 2014 à 18:38, Martin-Éric Racine 
martin-eric.rac...@iki.fi a écrit :

Package: desktop-base
Followup-For: Bug #756988

While 8.0.1 in principle introduced new background images for GDM 
(Thanks!), GDM still shows its default gray background.


Running 'gksudo -u Debian-gdm gnome-tweak-tool' confirms that 
lines.xml and lines-lockscreen.xml are correctly configured in the 
dconf keys, so I'm guessing that the problem is somewhere else e.g. 
hard-coded paths in the gdm3 package.


Hi Martin-Éric,

In fact, there is no issue. Only the default *lock* screen background 
has been changed.
The *login* screen background is hard-coded in 
'/usr/share/gnome-shell/theme/gnome-shell.css'

(see the '#lockDialogGroup' CSS ID).

Cheers,
Vincent


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756988: desktop-base: please provide a background for GDM 3 and its screen lock mode

2014-12-27 Thread Martin-Éric Racine

2014-12-27 19:58 GMT+02:00 Vincent Blut vincent.deb...@free.fr:
 Le sam. 27 déc. 2014 à 18:38, Martin-Éric Racine martin-eric.rac...@iki.fi
 a écrit :

 Package: desktop-base
 Followup-For: Bug #756988

 While 8.0.1 in principle introduced new background images for GDM
 (Thanks!), GDM still shows its default gray background.

 Running 'gksudo -u Debian-gdm gnome-tweak-tool' confirms that lines.xml
 and lines-lockscreen.xml are correctly configured in the dconf keys, so I'm
 guessing that the problem is somewhere else e.g. hard-coded paths in the
 gdm3 package.


 Hi Martin-Éric,

 In fact, there is no issue. Only the default *lock* screen background has
 been changed.
 The *login* screen background is hard-coded in
 '/usr/share/gnome-shell/theme/gnome-shell.css'
 (see the '#lockDialogGroup' CSS ID).

Good to know.

I'm just surprised that this would not default to the new theme, since
previous Debian releases would configure the GDM background to
whatever theme would be the default provided by desktop-base.

Martin-Éric


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/debian-bugs-dist

Bug#773180: (pre-approval) unblock: dbus with #773107 fixed

2014-12-27 Thread Cyril Brulebois

Ivo De Decker iv...@debian.org (2014-12-26):
 Control: retitle -1 unblock: dbus/1.8.12-3
 
 Hi,
 
 On Sat, Dec 20, 2014 at 11:23:45PM +0100, Cyril Brulebois wrote:
  Julien Cristau jcris...@debian.org (2014-12-15):
   Control: tag -1 confirmed d-i
   
   On Mon, Dec 15, 2014 at 11:05:51 +, Simon McVittie wrote:
   
Package: release.debian.org
Severity: wishlist
User: release.debian@packages.debian.org
Usertags: unblock

I just uploaded a dbus version to experimental with more robust
owner/permissions setting for dbus-daemon-launch-helper (debdiff
attached). Would you be willing to consider equivalent changes via
unstable (probably as dbus/1.8.12-2) for jessie?

   Seems fine to me, though it should be d-i-acked.
  
  No objection.
 
 Another dbus upload happened, which was unblocked by Niels, but needs an
 unblock-udeb: […]

Still no objection.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#774017: unblock: lzo2/2.08-1.2

2014-12-27 Thread Cyril Brulebois

Jonathan Wiltshire j...@debian.org (2014-12-27):
 Package: release.debian.org
 Severity: normal
 Tags: d-i
 User: release.debian@packages.debian.org
 Usertags: unblock
 
 Please unblock package lzo2
 
 Simon McVittie NMUd lzo2 to fix a crash in openvpn, RC bug #757037. The
 attached debdiff covers -1.1 and -1.2 since the first fix was incomplete.
 
 Unblocked, but needs a kibi-ack for the udeb please.

2014-12-21 01:08:05[ KiBi] ivodd: will try to look at lzo2 before falling asleep
2014-12-21 01:14:55[ KiBi] ivodd: the fact it needed a second upload makes me 
somewhat nervous

lzo2's udeb seems to be only used by btrfs-tools-udeb though…

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#772862: Pending dpkg upload will Break your package due to trigger cycle in your package

2014-12-27 Thread Niels Thykier

Hi,

This package appears to have a trigger cycle causing upgrade issues from
Wheezy to Jessie.  To fix this issue, you need upload a patched version
without this cycle *and* dpkg needs to be upgraded prior to your
package.  The latter is solved by making dpkg Breaks your package.

I have requested that the dpkg maintainers go ahead and add the Breaks
on their next upload - meaning *this package may become uninstallable in
unstable in the near future*.  This request was based on the assumption
that the upload will fix some of them outstanding upgrade issues (see
our Jenkins upgrade tests[1][2])

To my knowledge the affected packages are:

 * auctex - key package (i.e. no automatic removal)
 * wordpress - to be automatically removed on January 24th.
   - Craig: I am aware of the version in NEW.  However, given it is
 in NEW, I doubt it will comply with the freeze policy.  Do contact
 the release team if you believe otherwise.
 * gxine - to be automatically removed on January 9th.
 * icecc - to be automatically removed on January 24th.

I strongly urge you to resolve the trigger issue really soon now.  For
the non-key packages, they *will be manually removed from testing* if
they stall the dpkg migrating to testing *on (or after) January 5th*.
  For auctex, I am pondering between an NMU or manual removal as well
depending on the fallout of removing the package.  Please consider this
mail an /intend to NMU/ switching to no-await triggers.

If you already know what the resolution is for your bug, but simply do
not have time to implement it before January 5th then - *promptly*
follow up to the bug affecting your package *CC'ing me* explaining the
desired solution and including a permission for an NMU to implement this
solution.

I apologise for the short notice and for the rather resolute mail.
However, I strongly believe that we need to resolve the Jessie upgrade
issues sooner rather than later - especially considering we are not soon
two months into the freeze.

As a minor band-aid - If your package is manually removed *before* the
date set by the automatic removal tool (see above), your deadline for
getting your package back in testing is 7 days after the date set above
*OR* February 5th (whichever comes first).  For auctex (assuming it is
removed), the deadline will be February 5th.
  Please see the freeze policy[3] for the details of getting your
package back into testing.  If you want to make use of this extended
deadline, please remember to quote this mail when doing so.

Thanks for your understanding,
~Niels

[1]
https://jenkins.debian.net/job/chroot-installation_wheezy_bootstrap_upgrade_to_jessie/

[2]
https://jenkins.debian.net/job/chroot-installation_wheezy_bootstrap_upgrade_to_jessie_aptdpkg_first/

[3] https://release.debian.org/jessie/freeze_policy.html


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774031: r-base-dev: please do not write username and current time when building packages

2014-12-27 Thread Jérémy Bobbio

Package: r-base-dev
Version: 3.1.2-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain username timestamps

Hi!

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

The username and build time gets written to the `Packaged` field in
`package.rds`. The build time also gets written to the `Built` field of
the `DESCRIPTION` file.

This data does not look very useful in the context of Debian packages.
The attached patch simply stops writing the `Packaged` field entirely
and remove the build time from the `Built` field. R packages can then be
built reproducibly according to some preliminary tests.

If this approach is seen as too broad, using the timestamp in the latest
debian/changelog entry through an environment variable would allow to
keep a timestamp. My current R skills are not up to such task, though.
The username should probably be removed or made constant in any cases.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -u r-base-3.1.2/debian/changelog r-base-3.1.2/debian/changelog
--- r-base-3.1.2/debian/changelog
+++ r-base-3.1.2/debian/changelog
@@ -1,3 +1,11 @@
+r-base (3.1.2-2.0~reproducible1) UNRELEASED; urgency=low
+
+  * Stop writing a Packaged field when building a package as it was writing the
+username and current time, preventing reproducible builds.
+  * Remove the build timestamp from the Built field for the same reason.
+
+ -- Jérémy Bobbio lu...@debian.org  Sat, 27 Dec 2014 17:23:50 +
+
 r-base (3.1.2-2) unstable; urgency=low
 
   * debian/control: Upgrade Build-Depends: to tcl and tk 8.6
only in patch2:
unchanged:
--- r-base-3.1.2.orig/src/library/tools/R/admin.R
+++ r-base-3.1.2/src/library/tools/R/admin.R
@@ -65,11 +65,7 @@
 	   paste(R.version[c(major, minor)], collapse = .),
 	   ; ,
 	   if(file_test(-d, file.path(dir, src))) OStype else ,
-	   ; ,
-	   ## Prefer date in ISO 8601 format, UTC.
-	   format(Sys.time(), tz = UTC, usetz = TRUE),
-	   ## Sys.time(),
-	   ; ,
+	   ; ; ,
 	   .OStype())
 
 ## At some point of time, we had:
only in patch2:
unchanged:
--- r-base-3.1.2.orig/src/library/tools/R/build.R
+++ r-base-3.1.2/src/library/tools/R/build.R
@@ -149,18 +149,6 @@
 Report bugs at bugs.r-project.org ., sep = \n)
 }
 
-add_build_stamp_to_description_file - function(ldpath) {
-db - .read_description(ldpath)
-## this is an optional function, so could fail
-user - Sys.info()[user]
-if(user == unknown) user - Sys.getenv(LOGNAME)
-db[Packaged] -
-sprintf(%s; %s,
-format(Sys.time(), '', tz = 'UTC', usetz = TRUE),
-user)
-.write_description(db, ldpath)
-}
-
 ## FIXME
 ## This should really be combined with
 ## add_build_stamp_to_description_file().
@@ -930,9 +918,6 @@
 ## Fix permissions for all files to be at least 644, and dirs 755
 ## Not restricted by umask.
 	if (!WINDOWS) .Call(dirchmod, pkgname, group.writable=FALSE)
-## Add build stamp to the DESCRIPTION file.
-add_build_stamp_to_description_file(file.path(pkgname,
-  DESCRIPTION))
 ## Add expanded R fields to the DESCRIPTION file.
 add_expanded_R_fields_to_description_file(file.path(pkgname,
 DESCRIPTION))


signature.asc
Description: Digital signature

Bug#773714: unblock: grub2/2.02~beta2-19

2014-12-27 Thread Cyril Brulebois

Control: tag -1 confirmed

Ivo De Decker iv...@debian.org (2014-12-26):
 On Mon, Dec 22, 2014 at 02:56:09PM +, Ian Campbell wrote:
  Please unblock package grub2
 
  Version -18 added a fix for #767037 (workaround for buggy EFI 
  implementations)
  which included a new debconf template. -19 adds translations for the new
  template (including a wording fix to the English) and fixes two issues with
  that new funcitionality (one, #773092, is important, the other, #773004, is
  fairly minor but quite irritating in practice).
  
  I also added a README.source.
  
  Note that this upload does not include the upstream translation updates
  discussed in preapproval bug #773224, since there wasn't an obvious yes to 
  that
  question.
 
 Unblocked, but this also needs an unblock-udeb.

ACK.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#772624: dmesg output

2014-12-27 Thread Ben Hutchings

Control: reassign -1 src:linux 3.16.7-2

On Thu, 25 Dec 2014 22:22:28 +0100 Martin Vlk mar...@vlkk.cz wrote:
 Another observation - when I wake up the laptop mouse doesn't work and I see
 the following in the log.
[...]
 This does look like kernel issue, right? I'll see if I find out how to
 reassign this bug. Can I do anything else to help the resolution of this
 problem?

Yes I think it's a kernel issue.  (Well, it may be a hardware issue but
the kernel should work around it if possible.)

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Bug#773980: libmagickcore-6.q16-2: 8:6.8.9.9-4 breaks images in GNU Emacs 24 (displayed as single colour rectangles)

On Sat, Dec 27, 2014 at 3:11 PM, Adam Sjøgren a...@koldfront.dk wrote:
 Bastien writes:

 On Fri, Dec 26, 2014 at 10:24 PM, Adam Sjøgren a...@koldfront.dk wrote:
 Bastien writes:

 When displaying an image in GNU Emacs 24 (package emacs24), after
 upgrading from ImageMagick 8:6.8.9.9-3 to 8:6.8.9.9-4, images with
 :type 'imagemagick are displayed as single colour rectangles.

 Thanks could you get the exact command running ?

 I don't understand your question.

 I suppose emacs execute imagmagick. Thus that is the command (shell)
 and parameter that emacs use ?

 I don't think Emacs executes any ImageMagick commands - Emacs is linked
 to the ImageMagick libraries, which is why I reported the bug against
 libmagickcore-6, and not on the package with the binaries.

 I.e.:

   $ ldd /usr/bin/emacs24 | grep -i magick
   libMagickWand-6.Q16.so.2 = 
 /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2 (0x7f7d415b8000)
   libMagickCore-6.Q16.so.2 = 
 /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2 (0x7f7d410f8000)
   $

 And this is also why the recipe for reproducing the problem I wrote
 includes running Emacs.


It seems it is only xpm file. Could you try with other format of input
image ? I have applied some patch to xpm coder in order to solve
security problem. Will try to reproduce.

Staying in -3 is not a solution due to the security problem.

Bastien


 I hope this clears it up.


   Best regards,

 Adam

 --
  May the force be... Adam Sjøgren
   ... equal to mass · acceleration  a...@koldfront.dk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773965: binNMUed db5.3 FTBFS due to --link-doc check

2014-12-27 Thread Bernhard R. Link

* Helmut Grohne hel...@subdivi.de [141226 11:06]:
 My attempt to cross build db5.3 for x32 from amd64 failed. A log is
 attached. The relevant bits are:
 
 | dh_installdocs -pdb5.3-doc -plibdb5.3-java
 | dh_installdocs: No packages to build.
 | dh_installdocs --remaining-packages --link-doc=libdb5.3
 | dh_installdocs: WARNING: --link-doc between architecture all and not all 
 packages breaks binNMUs
 | dh_installdocs: Aborting build as this is a binNMU (leading to a broken 
 package)
 | debian/rules:250: recipe for target 'override_dh_installdocs' failed
 
 As you can see, this is not specific to cross building. Looking closer
 at the db5.3 source package one can see that it only builds two arch:all
 packages. Those are db5.3-doc and libdb5.3-java. Given the
 --remaining-packages switch in the second dh_installdocs invocation, it
 does not cover any arch:all packages and thus should not error out.
 
 In theory, debhelper does cover for --remaining-packages in
 dh_installdocs. I do not see why this mechanism does not work for db5.3.
 I hope that someone can figure this out.

The problem seems to be 97993b514bfbcc84c213e9e5d68c1b1c3a833ce7
(the commit introducing INTERNAL_EXCL_DOPACKAGES).
With that commit reverted it work as far as my limited tests concluded.

I think the key here is that the binary-arch is called, which causes
debhelper to limit everything to architecture dependent packages.

As above commit causes dh_installdoc --link-doc to specifically also
look at packages excluded because of this it looks at the packages
thus causes this false positive.

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774032: zoo: segmentation fault


Package: zoo
Version: 2.10-27+b1
Usertags: afl

zoo crashes when unpacking the attached (slightly corrupted) archive:

$ zoo x crash.zoo
Segmentation fault


This bug was found using American fuzzy lop:
https://packages.debian.org/experimental/afl

Disclaimer: I don't have spare CPU cycles, so I fuzzed only till the 
first crash (which took only a few seconds). It's likely that extensive 
fuzzing would discover more interesting crashers. I'd encourage zoo 
maintainers to perform fuzzing with AFL on their own. :-)


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

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

Versions of packages zoo depends on:
ii  libc6  2.19-13

--
Jakub Wilk


crash.zoo
Description: Binary data

Bug#774031: r-base-dev: please do not write username and current time when building packages

2014-12-27 Thread Dirk Eddelbuettel


(CCing upstream)

Salut Jérémy,

On 27 December 2014 at 19:26, Jérémy Bobbio wrote:
| Package: r-base-dev
| Version: 3.1.2-2
| Severity: wishlist
| Tags: patch
| User: reproducible-bui...@lists.alioth.debian.org
| Usertags: toolchain username timestamps
| 
| Hi!
| 
| While working on the “reproducible builds” effort [1], we have noticed
| that R packages could not be built reproducibly.
| 
| The username and build time gets written to the `Packaged` field in
| `package.rds`. The build time also gets written to the `Built` field of
| the `DESCRIPTION` file.

That's standard R behaviour which I'd rather not deviate from (as I don't
believe in maintaining local patches for a long time -- and I have looked
after this for a decade or more).
 
| This data does not look very useful in the context of Debian packages.
| The attached patch simply stops writing the `Packaged` field entirely
| and remove the build time from the `Built` field. R packages can then be
| built reproducibly according to some preliminary tests.
| 
| If this approach is seen as too broad, using the timestamp in the latest
| debian/changelog entry through an environment variable would allow to
| keep a timestamp. My current R skills are not up to such task, though.
| The username should probably be removed or made constant in any cases.

I think the idea may have some merit. 

If someone from R Core has some sympathy for the request, I can probably work
up a similarly small patch which suppresses this output if an option or flag
has been set.

But without cooperation from R Core, I don't think the Debian package should
deviate. 

Cheers,  Dirk

| 
|  [1]: https://wiki.debian.org/ReproducibleBuilds
| 
| -- 
| Lunar.''`. 
| lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
| `. `'` 
|   `-   
| x[DELETED ATTACHMENT r-base_3.1.2-2_reproducible0.diff, text/x-diff]
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773980: libmagickcore-6.q16-2: 8:6.8.9.9-4 breaks images in GNU Emacs 24 (displayed as single colour rectangles)

control: tags -1 + confirmed

Hi,

I found it

In order to reproduce run
convert rose: rose.xpm
display rose.xpm

it should show strange stuff.

The problematic commit is http://trac.imagemagick.org/changeset/17297
and it is needed from a security point of view :S

Will see we upstream

On Sat, Dec 27, 2014 at 8:01 PM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
 On Sat, Dec 27, 2014 at 3:11 PM, Adam Sjøgren a...@koldfront.dk wrote:
 Bastien writes:

 On Fri, Dec 26, 2014 at 10:24 PM, Adam Sjøgren a...@koldfront.dk wrote:
 Bastien writes:

 When displaying an image in GNU Emacs 24 (package emacs24), after
 upgrading from ImageMagick 8:6.8.9.9-3 to 8:6.8.9.9-4, images with
 :type 'imagemagick are displayed as single colour rectangles.

 Thanks could you get the exact command running ?

 I don't understand your question.

 I suppose emacs execute imagmagick. Thus that is the command (shell)
 and parameter that emacs use ?

 I don't think Emacs executes any ImageMagick commands - Emacs is linked
 to the ImageMagick libraries, which is why I reported the bug against
 libmagickcore-6, and not on the package with the binaries.

 I.e.:

   $ ldd /usr/bin/emacs24 | grep -i magick
   libMagickWand-6.Q16.so.2 = 
 /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2 (0x7f7d415b8000)
   libMagickCore-6.Q16.so.2 = 
 /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2 (0x7f7d410f8000)
   $

 And this is also why the recipe for reproducing the problem I wrote
 includes running Emacs.


 It seems it is only xpm file. Could you try with other format of input
 image ? I have applied some patch to xpm coder in order to solve
 security problem. Will try to reproduce.

 Staying in -3 is not a solution due to the security problem.

 Bastien


 I hope this clears it up.


   Best regards,

 Adam

 --
  May the force be... Adam Sjøgren
   ... equal to mass · acceleration  a...@koldfront.dk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774033: debian-lan-config: diskless clients do not work: deadlock

2014-12-27 Thread Andreas B. Mundt

Package: debian-lan-config
Version: 0.18
Severity: normal

Hi,

currently diskless machines seem not to work.  On login, the user is
authenticated successfully, but the machine kind of deadlocks
immediately (perhaps on mounting the home directory?) and no prompt is
shown.

Regards,

Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773739: [Pkg-xfce-devel] Bug#773739: xfce4-settings: 'Startup and Sessions' changes to not 'take'

2014-12-27 Thread Yves-Alexis Perez

control: reassign -1 xfce4-session
control: tag -1 moreinfo unreproducible
On lun., 2014-12-22 at 15:38 -0500, Daniel Dickinson wrote:
 Package: xfce4-settings
 Version: 4.10.1-2
 Severity: important
 
 Dear Maintainer,
 
 Changing things in 'Startup and Sessions' (e.g. checking or unchecking
 items in the startup list, or adding item) fails to actually do anything.
 When you exit and reenter the dialogue no change has occurred for 
 checking/unchecking, and in the case of adding an item the dialogue reports
 that it was unable to add 'autostart/item.desktop'.  Perhaps it is 
 attempting
 to acess /etc/xdg/autostart intead of ~/.config/autostart?

Looks like XDG_CONFIG_HOME is set to something wrong, can you check
that?
-- 
Yves-Alexis


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

Bug#773743: [Pkg-xfce-devel] Bug#773743: xfce4-power-manager: Suspend fails (requests authentication in order to suspend)

2014-12-27 Thread Yves-Alexis Perez

control: tag -1 moreinfo unreproducible
On lun., 2014-12-22 at 15:41 -0500, Daniel Dickinson wrote:
 Suspend mode is never entered via power-manager due to the fact that when it
 comes times to suspend an authentication dialogue requesting authorization
 to suspend pops up instead of suspend occurring.

Looks like you have issues with your policykit config then, but there's
not enough information here to know what.
-- 
Yves-Alexis


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

Bug#773913: [Pkg-xfce-devel] Bug#773913: Lightdm switches immediately to a black screen

2014-12-27 Thread Yves-Alexis Perez

control: tag -1 unreproducible moreinfo
control: severity -1 important

On jeu., 2014-12-25 at 16:19 +0100, Fabien Renaud wrote:
 Package: lightdm
 Version: 1.10.3-3
 Severity: grave
 Justification: renders package unusable
 
 Dear Maintainer,
 
 *** Reporter, please consider answering these questions, where appropriate ***
 
* What led up to the situation?
 I think it happened after an important upgrade related to systemd
 a few months ago but I'm not fully sure. I'm now using
 systemd-logind.

What am I supposed to do with that?
 
* What was the outcome of this action?
 Notice that I report the bug with a different kernel.
 The kernel on which the bug occurs is: Linux 3.16-2-amd64
 
 Lightdm starts and instantly (maybe after 1/10 sec) shows a
 black screen.
 It is possible to login (I can see that the HDD light working) but
 the screen is still black.

LightDM doesn't control the screen brightness, so it's look completely
unrelated to lightdm.

  I'm reporting this for lightdm but I
 guess this is more general.

Indeed.

 Notice that when I use another kernel (3.14-2-amd64) the situation
 is a bit different: the screen is black but if I increase the
 luminosity of the screen then it suddenly works.

So why are you reporting against lightdm if it looks like a kernel
regression?
 
 
* What outcome did you expect instead?
 To be able at least to increase the luminosity until it works.
 The best would be of course to have immediately a screen with display
 on.

In any case, there's nothing I can do with the report, sorry.

Regards,
-- 
Yves-Alexis


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

Bug#357446: pinfo: UTF8 problems

2014-12-27 Thread Stepan Golosunov

27.12.2014 в 16:41:35 +0100 Bas Zoetekouw написал:
 Hi Stephan,

Hi

  Pinfo still has problems displaying utf-8: - links are highlighted
  in the wrong place - з (CYRILLIC SMALL LETTER ZE) is replaced
  with o, usually with next character - it also results in
  misaligned right edge of text - searched strings are highlighted in
  wrong places
 
 I was looking into this bug, but it seems the gpg package no longer
 supplies the Russian info pages.  Could you maybe point me to a
 location or a package where I can get them?

It was man page, not info page. Anything in /usr/share/man/ru/man?
should be enough. I can reproduce this bug with pinfo man.

Nowadays first з on a line appears to be replaced by a space. Some
of the colored words are misplaced (those that are located after
з?). Highlighting of search results is misplaced if there are
non-ascii characters before it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774034: O: zoo -- manipulate zoo archives

2014-12-27 Thread Jari Aalto

Package: wnpp
Severity: normal

Description: manipulate zoo archives
 Zoo is used to create and maintain collections of files in
 compressed form. It uses a Lempel-Ziv compression algorithm
 that gives space savings in the range of 20% to 80%
 depending on the type of file data. Zoo can store and
 selectively extract multiple generations of the same file.
 .
 This package exists for its historical value. If you are
 looking for a compression tool for serious use, check tar
 and gzip.

I no longer have use for this program. The package is in
otherwise in a good shape: standard 3.9.4, debhelper 9,
Pacakging format 3.0 (quilt),

Copyright format 1.0

For a prospective new maintainer:

Start maintaining the package from Git[*]

git clone
$lo...@git.debian.org:/git/collab-maint/zoo.git

PTS: http://packages.qa.debian.org/z/zoo.html

Jari

[*]
http://wiki.debian.org/Alioth/Git
http://wiki.debian.org/Alioth/Git#Collab_Maint_project


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773980: libmagickcore-6.q16-2: 8:6.8.9.9-4 breaks images in GNU Emacs 24 (displayed as single colour rectangles)

On Sat, Dec 27, 2014 at 8:33 PM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
 control: tags -1 + confirmed

 Hi,

 I found it

 In order to reproduce run
 convert rose: rose.xpm
 display rose.xpm

 it should show strange stuff.

 The problematic commit is http://trac.imagemagick.org/changeset/17297
aka
fcf54f0b0f1a277f2e480ac37d731c6a0e5eb473
 and it is needed from a security point of view :S

 Will see we upstream

 On Sat, Dec 27, 2014 at 8:01 PM, Bastien ROUCARIES
 roucaries.bast...@gmail.com wrote:
 On Sat, Dec 27, 2014 at 3:11 PM, Adam Sjøgren a...@koldfront.dk wrote:
 Bastien writes:

 On Fri, Dec 26, 2014 at 10:24 PM, Adam Sjøgren a...@koldfront.dk wrote:
 Bastien writes:

 When displaying an image in GNU Emacs 24 (package emacs24), after
 upgrading from ImageMagick 8:6.8.9.9-3 to 8:6.8.9.9-4, images with
 :type 'imagemagick are displayed as single colour rectangles.

 Thanks could you get the exact command running ?

 I don't understand your question.

 I suppose emacs execute imagmagick. Thus that is the command (shell)
 and parameter that emacs use ?

 I don't think Emacs executes any ImageMagick commands - Emacs is linked
 to the ImageMagick libraries, which is why I reported the bug against
 libmagickcore-6, and not on the package with the binaries.

 I.e.:

   $ ldd /usr/bin/emacs24 | grep -i magick
   libMagickWand-6.Q16.so.2 = 
 /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2 (0x7f7d415b8000)
   libMagickCore-6.Q16.so.2 = 
 /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2 (0x7f7d410f8000)
   $

 And this is also why the recipe for reproducing the problem I wrote
 includes running Emacs.


 It seems it is only xpm file. Could you try with other format of input
 image ? I have applied some patch to xpm coder in order to solve
 security problem. Will try to reproduce.

 Staying in -3 is not a solution due to the security problem.

 Bastien


 I hope this clears it up.


   Best regards,

 Adam

 --
  May the force be... Adam Sjøgren
   ... equal to mass · acceleration  a...@koldfront.dk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774024: libglib2.0-dev: glib python macros not enabled - wrong location gdb autoload directory

Le Sat, 27 Dec 2014 17:55:33 +0100,
Laurent Bigonville bi...@debian.org a écrit :

 
 So I guess that the new paths should be the following then:
 
 /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.1-gdb.py
 /usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1-gdb.py

I'm also wondering if these shouldn't be moved to the -dbg package
actually.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774035: debian-lan-config: di-netboot-assistant setup fails

2014-12-27 Thread Andreas B. Mundt

Package: debian-lan-config
Version: 0.18
Severity: normal

Hi,

related to #759424, the setup of the PXE installer fails.   With the
current di-netboot-assistant package, no PXE environment is set up.

Debian-lan-config tries to install the distribution
   DISTRI=$(sed s%/.*$%% ${target}/etc/debian_version)
in scripts/FAISERVER/50-di-netboot which sets DISTRI to 8.0 now.
Available are only the codenames up to wheezy, as well as testing and
stable.

Workaround:  Hardcode 'DISTRI=testing' now and 'DISTRI=stable' after
the release to make sure jessie is provided via PXE.

Regards,

   Andi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#369120: table is corrupt while viewing cpp infopage

2014-12-27 Thread Bas Zoetekouw

Hi Justin,

I'm currently looking into some ancient pinfo bugs.  Among these is yours:

 Implementation-defined behavior (near the bottom)
 Scroll down one line at a time, using the down arrow; in an 25 row
   xterm, I go down 13 times.
 Notice the *Note fdollars-in-identifiers::.  reference.  It is in
 red, which means that it is a hyperlink to another part of the info
 manual.  Press enter to try to follow the reference.  
 Actual Result:
   Tag table is corrupt, trying to fix... (press a key to continue)
 Expected result:
 Some documentation for that option.

The good news is that I can reproduce the isseu with cpp-doc-4.9.

The bad new is that the problem seems to be that pinfo currently only
supports Node hyperlinks and not Anchors (see
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Info-Format-Tag-Table.html
for the difference between those).  Specifically, pinfo assumes all
links are to Nodes, and so after seeking to the correct file position,
it looks for the first new Node below.  This explains why you are
getting section 13 instead of the reference to the specific option you
were looking for (which is in section 12).

This is not quite easy to solve, and I'm not sure that it is doable
without rewriting all of the tag table code...
I'll think some more about an easy fix...

Gr,
Bas.



signature.asc
Description: OpenPGP digital signature

Bug#774036: linux-image-3.16.0-4-amd64: poweroff after suspend or hibernate does not work anymore after upgrade wheezy - jessie

2014-12-27 Thread Rainer Dorsch

Package: src:linux
Version: 3.16.7-ckt2-1
Severity: normal

Dear Maintainer,

I upgraded from wheezy to jessie and after the upgrade, suspend and hibernate 
are not fully functional anymore.

Hibernate works, but the final power off does not work. If I do a hard reboot, 
the resume works flawless.

For suspend, there is also no power off and consequently I cannot restart and I 
have to reboot.

For wheezy, I had similar symptoms, there adding

acpi_sleep=old_ordering

to the kernel cmdline solved the issue for the wheezy kernel 3.2.x, but it does 
not solve the issue for the 3.16.x kernel from jessie.

I see the same behavior when starting the suspend process with KDE, with 
systemctl suspend or even when I just

echo mem  /sys/power/state

I follow

https://01.org/linuxgraphics/documentation/how-debug-suspend-resume-issues-0

and provide more debug information.


Since I do not have permanent access to the system, it would be useful, if you 
can tell me soon, if there is particularly important information to collect.

Many thanks,
Rainer

-- Package-specific info:
** Version:
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.8.3 (Debian 4.8.3-16) ) #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=UUID=d47ae970-51f3-48d3-b19d-edd7413e080f ro quiet elevator=noop 
rootflags=noatime,discard,data=ordered,errors=remount-ro acpi_sleep=old_ordering

** Tainted: PWO (4609)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
[  486.009299] pci :00:01.5: no hotplug settings from platform
[  486.009301] pci :00:01.5: using default PCI settings
[  486.009310] pci :00:01.6: no hotplug settings from platform
[  486.009313] pci :00:01.6: using default PCI settings
[  486.009321] pci :00:02.0: no hotplug settings from platform
[  486.009324] pci :00:02.0: using default PCI settings
[  486.009333] pci :00:02.1: no hotplug settings from platform
[  486.009336] pci :00:02.1: using default PCI settings
[  486.009346] pci :00:02.2: no hotplug settings from platform
[  486.009348] pci :00:02.2: using default PCI settings
[  486.009358] pcieport :00:03.0: no hotplug settings from platform
[  486.009370] nvidia :01:00.0: no hotplug settings from platform
[  486.009375] pci :00:09.0: no hotplug settings from platform
[  486.009378] pci :00:09.0: using default PCI settings
[  486.009391] pci :00:0a.0: no hotplug settings from platform
[  486.009394] pci :00:0a.0: using default PCI settings
[  486.009403] nForce2_smbus :00:0a.1: no hotplug settings from platform
[  486.009406] nForce2_smbus :00:0a.1: using default PCI settings
[  486.009416] pci :00:0a.2: no hotplug settings from platform
[  486.009418] pci :00:0a.2: using default PCI settings
[  486.009428] ohci-pci :00:0b.0: no hotplug settings from platform
[  486.009431] ohci-pci :00:0b.0: using default PCI settings
[  486.009440] ehci-pci :00:0b.1: no hotplug settings from platform
[  486.009443] ehci-pci :00:0b.1: using default PCI settings
[  486.009452] pata_amd :00:0d.0: no hotplug settings from platform
[  486.009455] pata_amd :00:0d.0: using default PCI settings
[  486.009464] sata_nv :00:0e.0: no hotplug settings from platform
[  486.009467] sata_nv :00:0e.0: using default PCI settings
[  486.009475] sata_nv :00:0f.0: no hotplug settings from platform
[  486.009478] sata_nv :00:0f.0: using default PCI settings
[  486.009487] pci :00:10.0: no hotplug settings from platform
[  486.009489] pci :00:10.0: using default PCI settings
[  486.009504] b43-pci-bridge :02:06.0: no hotplug settings from platform
[  486.009507] b43-pci-bridge :02:06.0: using default PCI settings
[  486.009519] firewire_ohci :02:08.0: no hotplug settings from platform
[  486.009522] firewire_ohci :02:08.0: using default PCI settings
[  486.009533] snd_hda_intel :00:10.1: no hotplug settings from platform
[  486.009535] snd_hda_intel :00:10.1: using default PCI settings
[  486.009545] forcedeth :00:14.0: no hotplug settings from platform
[  486.009547] forcedeth :00:14.0: using default PCI settings
[  486.044596] done.
[  486.108414] cfg80211: World regulatory domain updated:
[  486.108421] cfg80211:  DFS Master region: unset
[  486.108423] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[  486.108427] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[  486.108431] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[  486.108434] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[  486.108437] cfg80211:   (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 
mBm), (N/A)
[  486.108440] cfg80211:   (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[

Bug#774006: RFP: libinline-python-perl -- write Perl subs and classes in Python

2014-12-27 Thread tony mancill

On 12/27/2014 08:43 AM, gregor herrmann wrote:
 On Fri, 26 Dec 2014 22:27:10 -0800, tony mancill wrote:
 
 * Package name: libinline-python-perl
   Version : 0.46
   Upstream Author : Stefan Seifert n...@cpan.org
 * URL : https://metacpan.org/release/Inline-Python
 * License : The Perl 5 License (Artistic 1  GPL 1)
   Programming Lang: Perl
   Description : write Perl subs and classes in Python
 
 Uploaded to NEW, git repo in pkg-perl.

Hello Gregor,

Thank you for the super-quick response to this RFP.  I had run
dh-make-perl and was in the midst of cleaning things up for a potential
ITP, but am glad if the Perl team will maintain this package.

In case you're curious, this module is used by squeezebox-googlemusic
[0] to allow the gmusicapi (Python) to run inside of the Logitech Media
Server (100% Perl).  Perhaps others will find it useful.

Cheers,
tony

[0] https://github.com/hechtus/squeezebox-googlemusic




signature.asc
Description: OpenPGP digital signature

Bug#773980: libmagickcore-6.q16-2: 8:6.8.9.9-4 breaks images in GNU Emacs 24 (displayed as single colour rectangles)

2014-12-27 Thread Adam Sjøgren

Bastien writes:

 I found it

Cool!

 The problematic commit is http://trac.imagemagick.org/changeset/17297
 and it is needed from a security point of view :S

 Will see we upstream

I guess there is a solution that satisfies both wishes.

Thanks much for looking into and pin-pointing this regression, very cool.


  Best regards,

Adam

-- 
 You make a hit by putting two flops together   Adam Sjøgren
 a...@koldfront.dk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763869: [Pkg-sysvinit-devel] Bug#763869: Bug#763869: sysvinit-utils: sulogin segfault after `cannot open password database!`

2014-12-27 Thread Henrique de Moraes Holschuh

On Fri, 26 Dec 2014, Petter Reinholdtsen wrote:
 Great.  The patch need to be moved to debian/patches/, but otherwise
 look good.  I hope someone with access to collab-maint can push a fix.
 Not sure if it will make it into Jessie.  It do not seem important
 enough to try to push it past the freeze.

We can simply push it through stable-proposed-updates once jessie is
released.  All that is required is heavy testing.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774037: rzip: segmentation fault