Bug#393056: nvidia-glx-ia32/experimental fails to install due to missing libGL.so diversion

[Török Edwin]

Package: nvidia-glx-ia32
Version: 1.0.9625-1
Followup-For: Bug #393056

This bug is still present in experimental.

Unpacking nvidia-glx-ia32 (from .../nvidia-glx-ia32_1.0.9625-1_amd64.deb) ...
dpkg: error processing 
/var/cache/apt/archives/nvidia-glx-ia32_1.0.9625-1_amd64.deb (--unpack):
trying to overwrite `/emul/ia32-linux/usr/lib/libGL.so', which is also in 
package ia32-libs
Errors were encountered while processing:
 /var/cache/apt/archives/nvidia-glx-ia32_1.0.9625-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-amd64
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages nvidia-glx-ia32 depends on:
ii  ia32-libs1.16ia32 shared libraries for use on a
ii  nvidia-kernel-2.6.18 1.0.9625-1+2.6.18-2 NVIDIA binary kernel module for Li

nvidia-glx-ia32 recommends no packages.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#604621: libclamav6: Clamscan and Clamd crash on Lenny32Bit/VIA-Cpu while scanning PDFs, Lenny32Bit/AMD works fine

[Török Edwin]

On Tue, 23 Nov 2010 07:23:33 +0100
Ralf Spenneberg  wrote:

> Package: libclamav6
> Version: 0.96.4+dfsg-1~volatile1
> Severity: important
> 
> 
> 
> -- System Information:
> Debian Release: 5.0.6
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 2.6.26-2-486
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages libclamav6 depends on:
> ii  libbz2-1.0 1.0.5-1+lenny1high-quality
> block-sorting file co ii  libc6  2.7-18lenny6
> GNU C Library: Shared libraries ii  libgcc1
> 1:4.3.2-1.1   GCC support library ii  libltdl3
> 1.5.26-4+lenny1   A system independent dlopen wrappe ii
> libstdc++6 4.3.2-1.1 The GNU Standard C++ Library
> v3 ii  libtommath00.39-3multiple-precision
> integer library ii  zlib1g 1:1.2.3.3.dfsg-12
> compression library - runtime
> 
> libclamav6 recommends no packages.
> 
> Versions of packages libclamav6 suggests:
> pn  libclamunrar6  (no description
> available)
> 
> -- no debconf information
> 
> Using clamscan or clamd to scan PDF files crashes the process on
> 32-Bit Lenny running on  VIA Samuel 2 CPU. Scanning the same file on
> AMD Athlon(tm) 64 X2 works fine. 
> I already checked the checksums of the files: ok.
> I already removed the clamav database and downloaded it again using
> freshclam. I rebooted the machine to fix any memory issues.
> The issue is reproducable every time.
> 
> Calling clamscan --debug on the file shows the following results
> (last lines): LibClamAV debug: cli_pdf: more than 2 filters per obj
> flagged in object 30 0 LibClamAV debug: cli_pdf: 30 0 obj flags: 10403
> LibClamAV debug: cli_pdf: 31 0 obj flags: 02
> LibClamAV debug: cli_pdf: 1 0 obj flags: 10023
> LibClamAV debug: cli_pdf: 2 0 obj flags: 02
> LibClamAV debug: cli_pdf: 3 0 obj flags: 02
> LibClamAV debug: cli_pdf: 4 0 obj flags: 02
> LibClamAV debug: cli_pdf: 5 0 obj flags: 02
> LibClamAV debug: cli_pdf: 6 0 obj flags: 02
> LibClamAV debug: cli_pdf: 7 0 obj flags: 02
> LibClamAV debug: cli_pdf: 8 0 obj flags: 03
> LibClamAV debug: cli_pdf: 9 0 obj flags: 02
> LibClamAV debug: Bytecode executing hook id 258 (2 hooks)
> LibClamAV debug: Bytecode 4: executing in JIT mode
> Illegal instruction (core dumped)

Hi Ralf,

Looks like a bug in the JIT.

Please install gdb, and run this command (using the attached gdbscript
file):
$ gdb -batch -x gdbscript -c core >log 2>&1

Where 'core' is the coredump created above (it might be core. or
something similar).
Then attach the file 'log' to this bugreport.

Also please provide the output of 'clamconf -n' (I'm interested in the
Platform information section), and 'cat /proc/cpuinfo' (I need the
family, model, and stepping mostly but please include all the output).

Best regards,
--Edwin

gdbscript
Description: Binary data

Bug#604621: libclamav6: Clamscan and Clamd crash on Lenny32Bit/VIA-Cpu while scanning PDFs, Lenny32Bit/AMD works fine

[Török Edwin]

On Tue, 23 Nov 2010 10:42:38 +0100
Ralf Spenneberg  wrote:

> Hi.
> 
> Thanks for the fast response.
> 
> Am Dienstag, den 23.11.2010, 11:00 +0200 schrieb Török Edwin:
> > Please install gdb, and run this command (using the attached
> > gdbscript file):
> > $ gdb -batch -x gdbscript -c core >log 2>&1
> I have problems running the gdbscript. The log contains:

Sorry, please use the newly attached gdbscript (apparently the gdb
version in lenny doesn't know about /mr).


> (no debugging symbols found)
> Core was generated by `clamscan --debug p003'.
> Program terminated with signal 4, Illegal instruction.
> [New process 31347]
> [New process 31434]
> #0  0xb17cbe2a in ?? ()
> /root/gdbscript:1: Error in sourced command file:
> A syntax error in expression, near `/mr'.
> 
> 
> > 
> > Also please provide the output of 'clamconf -n' (I'm interested in
> > the Platform information section),
> Platform information
> 
> uname: Linux 2.6.26-2-486 #1 Thu Sep 16 18:43:30 UTC 2010 i686
> OS: linux-gnu, ARCH: i386, CPU: i486
> zlib version: 1.2.3.3 (1.2.3.3), compile flags: 55
> Triple: i386-pc-linux-gnu
> CPU: generic, Little-endian

OK, that explains it, I'll update the bytecode.

Best regards,
--Edwin


gdbscript
Description: Binary data

Bug#604621: libclamav6: Clamscan and Clamd crash on Lenny32Bit/VIA-Cpu while scanning PDFs, Lenny32Bit/AMD works fine

[Török Edwin]

On Tue, 23 Nov 2010 13:59:28 +0100
Ralf Spenneberg  wrote:

> Hi,
> 
> attached is the log from the gdb.

Thanks, it is the CMOV instruction bug from Debian bug #600088, except
for a VIA CPU instead of an AMD K6-2 (neither of which support it).

I turned off the JIT for your CPU with bytecode.cvd version 93 (run
freshclam and you should get it soon).

Please keep the file that causes the crash though. 0.96.5 will reenable
the JIT (it fixes the underlying bug by not emitting the CMOV
instruction in the first place), so it would be good if you could test
that it doesn't crash (once it is released).

Best regards,
--Edwin



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

Bug#728798: [udisks] udisks-daemon: randomly starts using 100% CPU

[Török Edwin]

Package: udisks
Version: 1.0.4-8+b1
Severity: normal

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

Almost every other day udisks-daemon starts using 100% CPU (I notice because 
the CPU fan becomes louder).
I didn't plug/unplug or otherwise modify the state of any of my disks when that 
happens, and I don't have a reliable way to reproduce it either (other than 
wait a day or two to see if it starts using 100% CPU), hence I called it a 
random bug.

I usually just kill udisks-daemon when this happens, but this time I took a 
stacktrace and strace:

gdb stacktrace:

Thread 3 (Thread 0x7f4b24318700 (LWP 4309)):
#0  0x0033be6dd24d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x003ee6c48694 in g_main_context_poll (priority=2147483647, n_fds=3, 
fds=0x7f4b1c0010e0, timeout=-1, context=0x16a73d0)
at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:4006
#2  g_main_context_iterate (context=0x16a73d0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=)
at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:3707
#3  0x003ee6c48afa in g_main_loop_run (loop=0x16a7360) at 
/build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:3906
#4  0x0033e70cb9d6 in gdbus_shared_thread_func (user_data=0x16a73a0)
at /build/glib2.0-m8PF51/glib2.0-2.38.0/./gio/gdbusprivate.c:278
#5  0x003ee6c6d0e5 in g_thread_proxy (data=0x16a9450) at 
/build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gthread.c:798
#6  0x0033bf207e0e in start_thread (arg=0x7f4b24318700) at 
pthread_create.c:311
#7  0x0033be6e89ed in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7f4b23b17700 (LWP 5149)):
#0  0x0033be6dd24d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x003ee6c48694 in g_main_context_poll (priority=2147483647, n_fds=1, 
fds=0x7f4b140008c0, timeout=-1, context=0x1714b00)
at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:4006
#2  g_main_context_iterate (context=context@entry=0x1714b00, 
block=block@entry=1, dispatch=dispatch@entry=1, 
self=) at 
/build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:3707
#3  0x003ee6c4879c in g_main_context_iteration (context=0x1714b00, 
may_block=may_block@entry=1)
at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:3773
#4  0x003ee6c487e9 in glib_worker_main (data=) at 
/build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:5472
#5  0x003ee6c6d0e5 in g_thread_proxy (data=0x16a98a0) at 
/build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gthread.c:798
#6  0x0033bf207e0e in start_thread (arg=0x7f4b23b17700) at 
pthread_create.c:311
#7  0x0033be6e89ed in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7f4b24319800 (LWP 4297)):
#0  0x0033be6dd24d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x003ee6c48694 in g_main_context_poll (priority=2147483647, n_fds=6, 
fds=0x16945a0, timeout=663425, context=0x1690aa0)
at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:4006
#2  g_main_context_iterate (context=0x1690aa0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=)
at /build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:3707
#3  0x003ee6c48afa in g_main_loop_run (loop=0x16c1e40) at 
/build/glib2.0-m8PF51/glib2.0-2.38.0/./glib/gmain.c:3906
#4  0x00406f7c in ?? ()
#5  0x0033be621995 in __libc_start_main (main=0x406d70, argc=1, 
ubp_av=0x7fffbe72ac28, init=, 
fini=, rtld_fini=, stack_end=0x7fffbe72ac18) 
at libc-start.c:260
#6  0x004070d5 in ?? ()


strace shows that only poll is called, apparently in a tight loop:

Process 4297 attached - interrupt to quit
1383666498.282777 poll([{fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, 
events=0}, {fd=26, events=POLLIN}, {fd=23, events=POLLIN}, {fd=3, 
events=POLLIN}], 6, 1363008) = 2 ([{fd=26, revents=POLLHUP}, {fd=23, 
revents=POLLHUP}])
1383666498.282936 poll([{fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, 
events=0}, {fd=26, events=POLLIN}, {fd=23, events=POLLIN}, {fd=3, 
events=POLLIN}], 6, 1363008) = 2 ([{fd=26, revents=POLLHUP}, {fd=23, 
revents=POLLHUP}])
1383666498.283044 poll([{fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, 
events=0}, {fd=26, events=POLLIN}, {fd=23, events=POLLIN}, {fd=3, 
events=POLLIN}], 6, 1363008) = 2 ([{fd=26, revents=POLLHUP}, {fd=23, 
revents=POLLHUP}])
1383666498.283146 poll([{fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, 
events=0}, {fd=26, events=POLLIN}, {fd=23, events=POLLIN}, {fd=3, 
events=POLLIN}], 6, 1363008) = 2 ([{fd=26, revents=POLLHUP}, {fd=23, 
revents=POLLHUP}])
1383666498.283241 poll([{fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, 
events=0}, {fd=26, events=POLLIN}, {fd=23, events=POLLIN}, {fd=3, 
events=POLLIN}], 6, 1363008) = 2 ([{fd=26, revents=POLLHUP}, {fd=23, 
revents=POLLHUP}])
1383666498.283337 poll([{fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, 
events=0}, {fd=26, events=POLLIN}, {fd=23, events=POLLIN}, {fd=3, 
events=POLLIN}], 6, 1363008) = 2 ([{fd=26, revents=POLLHUP},

Bug#729436: [libc6-dev] strcasecmp declared twice

[Török Edwin]

Package: libc6-dev
Version: 2.17-93
Severity: normal

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

According to strcasecmp(3) and strcasecmp(3p) the function strcasecmp should be 
declared in strings.h.

However it is actually declared both in string.h and strings.h:
/usr/include/string.h:extern int strcasecmp (const char *__s1, const char *__s2)
/usr/include/string.h:extern int strcasecmp_l (const char *__s1, const char 
*__s2,
/usr/include/strings.h:extern int strcasecmp (const char *__s1, const char 
*__s2)
/usr/include/strings.h:extern int strcasecmp_l (const char *__s1, const char 
*__s2, __locale_t __loc)

If the declaration in string.h is a typo, please remove it.
Otherwise please update the manpage to mention that on Linux the function is 
actually declared in both string.h and strings.h, and you should check yourself 
that you included strings.h because you won't get any warning from the compiler 
about implicit declarations.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.12.0

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.ro.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#743416: [network-manager] network-manager shows non-sense buttons on desktop

[Török Edwin]

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

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

Looks like something went wrong with the last Network-manager update (0.9.8.0-5 
-> 0.9.8.8-4)
as it thinks my desktop is a phone or laptop.

When I click on the network-manager icon in KDE I see these buttons at the top:
Wireless disabled
Mobile broadband disabled
Airplane mode disabled

The box has ONE ethernet adapter, and thats it:
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 
PCI Express Gigabit Ethernet Controller (rev 09)

There is no wireless adapter, there is no mobile broadband adapter, there is no 
bluetooth, and there certainly isn't a way
to put my desktop into airplane mode.

I haven't seen these buttons before, so this must be a regression (or a new 
feature implemented wrongly).

Expected behaviour: when the hardware is missing don't show the button to 
enable/disable it,
i.e. if you got no WiFi hardware, don't show the wifi button, etc.
When you only have wired ethernet (and perhaps VPN on top of that) configured 
in network-manager, all other buttons should be hidden.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14-rc7-amd64

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 testing ftp.ro.debian.org 
  500 stable  repo.skylable.com 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-
libc6   (>= 2.14) | 
libdbus-1-3(>= 1.0.2) | 
libdbus-glib-1-2(>= 0.88) | 
libgcrypt11(>= 1.4.5) | 
libglib2.0-0  (>= 2.31.8) | 
libgnutls26(>= 2.12.17-0) | 
libgudev-1.0-0   (>= 165) | 
libmm-glib0  (>= 0.7.991) | 
libnl-3-200(>= 3.2.7) | 
libnl-genl-3-200   (>= 3.2.7) | 
libnl-route-3-200  (>= 3.2.7) | 
libnm-glib4  (>= 0.9.8.0) | 
libnm-util2(>= 0.9.7.995) | 
libpolkit-gobject-1-0   (>= 0.99) | 
libsoup2.4-1  (>= 2.26.1) | 
libsystemd-login0 (>= 31) | 
libuuid1(>= 2.16) | 
init-system-helpers(>= 1.18~) | 
lsb-base  (>= 3.2-14) | 
wpasupplicant(>= 0.7.3-1) | 
dbus   (>= 1.1.2) | 
udev  | 
adduser   | 
isc-dhcp-client   (>= 4.1.1-P1-4) | 


Recommends(Version) | Installed
===-+-===
policykit-1 | 0.105-4
ppp  (>= 2.4.5) | 2.4.5+git20130610-4
dnsmasq-base| 2.68-1
iptables| 1.4.21-1
modemmanager| 1.0.0-4
crda| 1.1.2-1
systemd | 204-8


Suggests   (Version) | Installed
-+-===
avahi-autoipd| 


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

Bug#743419: [plasma-nm] network-manager shows non-sense buttons on desktop

[Török Edwin]

Package: plasma-nm
Version: 0.9.3.3-2
Severity: normal

--- Please enter the report below this line. ---
[I wrongly filed this against the network-manager package initially, as there 
was no network-manager-kde]

Looks like something went wrong with the last Network-manager update as it 
thinks my desktop is a phone or laptop,
see attached screenshot with buttons: 

Wireless disabled
Mobile broadband disabled
Airplane mode disabled

The box has ONE ethernet adapter, and thats it:
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 
PCI Express Gigabit Ethernet Controller (rev 09)

There is no wireless adapter, there is no mobile broadband adapter, there is no 
bluetooth, and there certainly isn't a way
to put my desktop into airplane mode.

I haven't seen these buttons before, so this must be a regression (or a new 
feature implemented wrongly).

Expected behaviour: when the hardware is missing don't show the button to 
enable/disable it,
i.e. if you got no WiFi hardware, don't show the wifi button, etc.
When you only have wired ethernet (and perhaps VPN on top of that) configured 
in network-manager, all other buttons should be hidden.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14-rc7-amd64

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 testing ftp.ro.debian.org 
  500 stable  repo.skylable.com 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-=
mobile-broadband-provider-info  | 20140317-1
network-manager  (>= 0.9.8) | 0.9.8.8-4
kde-runtime (>> 4:4.10) | 4:4.11.5-1
libc6 (>= 2.14) | 
libgcc1(>= 1:4.1.1) | 
libkdecore5(>= 4:4.9.0) | 
libkdeui5  (>= 4:4.9.0) | 
libkio5(>= 4:4.9.0) | 
libknotifyconfig4  (>= 4:4.9.0) | 
libmodemmanagerqt1   (>= 1.0.1) | 
libnetworkmanagerqt1   (>= 0.9.8.1) | 
libopenconnect2   (>= 4.00) | 
libplasma3 (>= 4:4.9.0) | 
libqt4-dbus(>= 4:4.6.1) | 
libqt4-declarative (>= 4:4.7.0~rc1) | 
libqt4-network (>= 4:4.6.0) | 
libqt4-svg (>= 4:4.6.0) | 
libqt4-xml (>= 4:4.6.0) | 
libqtcore4 (>= 4:4.8.4) | 
libqtgui4  (>= 4:4.8.0) | 
libsolid4  (>= 4:4.9.0) | 
libstdc++6   (>= 4.1.1) | 


Recommends   (Version) | Installed
==-+-===
kwalletmanager | 4:4.11.3-1
network-manager-openvpn| 0.9.8.4-1
network-manager-pptp   | 0.9.8.4-1
network-manager-vpnc   | 0.9.8.6-1


Suggests (Version) | Installed
==-+-===
kde-workspace-bin  | 4:4.11.7-1+b1
network-manager-openconnect| 




<>

Bug#747058: [dispcalGUI] Missing __init__.py files

[Török Edwin]

Package: dispcalGUI
Version: 2.0.0.0-1
Severity: normal

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

See discussion here: 
https://groups.google.com/forum/#!msg/colorhug-users/QsPpCBI2dHM/ASWfFCarej0J

When I start dispcalGUI I get this error, which causes the 'Options -> Create 
display profile from extended...' menu entry to be grayed out:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dispcalGUI/wxMeasureFrame.py", line 
22, in 
import RealDisplaySizeMM as RDSMM
  File "/usr/lib/python2.7/dist-packages/dispcalGUI/RealDisplaySizeMM.py", line 
22, in 
from lib64.python27.RealDisplaySizeMM import *
ImportError: No module named lib64.python27.RealDisplaySizeMM

Comparing with the 0install feed of dispcalGUI (which doesn't show that error) 
it looks like the Debian package is missing a few files.
If I run this command as root then dispcalGUI doesn't show that error anymore, 
and the menu entry is no longer grayed out:
# touch /usr/lib/python2.7/dist-packages/dispcalGUI/lib64/python27/__init__.py 
/usr/lib/python2.7/dist-packages/dispcalGUI/lib64/__init__.py

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14-1-amd64

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 testing ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-=
libc6   (>= 2.4) | 
libx11-6 | 
libxinerama1 | 
libxrandr2  (>= 2:1.2.0) | 
libxxf86vm1  | 
python  (>= 2.7) | 
python  (<< 2.8) | 
python-wxgtk2.8  | 
python-numpy | 
argyll   | 


Recommends(Version) | Installed
===-+-===
colord  | 1.0.6-1
gir1.2-colordgtk-1.0| 0.1.25-1.1


Package's Suggests field is empty.


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

Bug#689337: ftp.ro.debian points to high latency CC

[Török Edwin]

Package: mirrors
Severity: normal

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

Since quite some time now ftp.ro.debian.org points to ftp.hr:
ftp.ro.debian.org is an alias for ftp.hr.debian.org.
ftp.hr.debian.org has address 161.53.160.11
ftp.hr.debian.org has IPv6 address 2001:b68:ff:1::11

The .hr mirror has quite high latency, so I'm using ftp.hu.debian.org and 
ftp.lug.ro
in my /etc/apt/sources.list now, otherwise the daily diff updates (lots of 
small files) take a long time.
In fact just downloading the full Contents.gz would be faster than waiting for 
all the diffs to be downloaded
from a mirror with such high latency.

I thought that the .hr was just a typo, and that it'd be fixed eventually, but 
since it was not
I opened this bugreport now.

ftp.hr.debian.org has a ping of 70ms, 21 hops, and 4.11MB/s.
Whereas ftp.hu.debian.org has a ping of 9ms, 11 hops, and 5.12MB/s.

Please point ftp.ro.debian.org to ftp.hu.debian.org.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.6.0-rc7

Debian Release: wheezy/sid
  500 unstableftp.lug.ro
  500 unstableftp.hu.debian.org
1 experimentalftp.lug.ro

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#693896: [siege] siege crashes on FQDN in URL

[Török Edwin]

Package: siege
Version: 2.70-4
Severity: normal

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

This crashes:
$ siege http://debian.home.lan/index.html
** SIEGE 2.70
** Preparing 15 concurrent users for battle.
The server is now under siege...Segmentation fault (core dumped)

This works:
$ siege http://debian/index.html
** SIEGE 2.70
** Preparing 15 concurrent users for battle.
The server is now under siege...

Both point to same IPv4 address:
$ host debian.home.lan
debian.home.lan has address 172.30.42.2
$ host debian
debian.home.lan has address 172.30.42.2

$ uname -a
Linux debian 3.6.6 #229 SMP PREEMPT Mon Nov 12 00:02:45 EET 2012 x86_64 
GNU/Linux

.siegerc and /var/tmp/urls is attached.

Here is a stacktrace, unfortunately there is no -dbg package so no symbols:
(gdb) bt
#0  __memcpy_sse2 () at ../sysdeps/x86_64/multiarch/../memcpy.S:90
#1  0x5556695f in ?? ()
#2  0xd3cd in ?? ()
#3  0xdff5 in start_routine ()
#4  0xf1c5 in ?? ()
#5  0x77bc7b50 in start_thread (arg=) at 
pthread_create.c:304
#6  0x770cba7d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x in ?? ()

If I compile siege 2.72 from upstream then there is no crash, so this seems to 
be a problem in Debian's 2.70 version.


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.6.6

Debian Release: wheezy/sid
  500 unstableftp.ro.debian.org
1 experimentalftp.ro.debian.org

--- Package information. ---
Depends  (Version) | Installed
==-+-===
libc6 (>= 2.7) |
libssl1.0.0 (>= 1.0.0) |


Package's Recommends field is empty.

Package's Suggests field is empty.



# Updated by Siege 2.70, October-08-2012
# Copyright 2000-2007 by Jeffrey Fulmer, et al.
# 
# Siege configuration file -- edit as necessary
# For more information about configuring and running
# this program, visit: http://www.joedog.org/

#
# Variable declarations. You can set variables here 
# for use in the directives below. Example:
# PROXY = proxy.joedog.org
# Reference variables inside ${} or $(), example: 
# proxy-host = ${PROXY} 
# You can also reference ENVIRONMENT variables without
# actually declaring them, example:
# logfile = $(HOME)/var/log/siege.log

#
# Signify verbose mode, true turns on verbose output
# ex: verbose = true|false
#
verbose = false

#
# CSV Verbose format: with this option, you can choose 
# to format verbose output in traditional siege format 
# or comma separated format. The latter will allow you 
# to redirect output to a file for import into a spread
# sheet, i.e., siege > file.csv 
# ex: csv = true|false (default false)
#
# csv = true

#
# Full URL verbose format: By default siege displays
# the URL path and not the full URL. With this option, 
# you # can instruct siege to show the complete URL.
# ex: fullurl = true|false (default false)
# 
# fullurl = true

#
# Display id: in verbose mode, display the siege user
# id associated with the HTTP transaction information
# ex: display-id = true|false
#
# display-id = 

#
# Show logfile location.  By default, siege displays the
# logfile location at the end of every run when logging
# You can turn this message off with this directive.
# ex: show-logfile = false
#
show-logfile = true

#
# Default logging status, true turns logging on.
# ex: logging = true|false
#
logging = true

#
# Logfile, the default siege logfile is /var/log/siege.log
# This directive allows you to choose an alternative log file.
# Environment variables may be used as shown in the examples:
# ex: logfile = /home/jeff/var/log/siege.log
# logfile = ${HOME}/var/log/siege.log
# logfile = ${LOGFILE}
#
logfile = /var/tmp/siege.log

#
# HTTP protocol.  Options HTTP/1.1 and HTTP/1.0.
# Some webservers have broken implementation of the
# 1.1 protocol which skews throughput evaluations.
# If you notice some siege clients hanging for
# extended periods of time, change this to HTTP/1.0
# ex: protocol = HTTP/1.1
# protocol = HTTP/1.0
#
protocol = HTTP/1.1

#
# Chunked encoding is required by HTTP/1.1 protocol
# but siege allows you to turn it off as desired.
# 
# ex: chunked = true 
# 
chunked = true

# 
# Cache revalidation.
# Siege supports cache revalidation for both ETag and 
# Last-modified headers. If a copy is still fresh, the 
# server responds with 304. 
# HTTP/1.1 200   0.00 secs:2326 bytes ==> /apache_pb.gif
# HTTP/1.1 304   0.00 secs:   0 bytes ==> /apache_pb.gif
# HTTP/1.1 304   0.00 secs:   0 bytes ==> /apache_pb.gif
# 
# ex: cache = true
#
cache = false

#
# Connection directive. Options "close" and "keep-alive"
# Starting with release 2.57b3, siege implements persistent 
# connections in accordance to RFC 2068 using both chunked
# encoding and content-length directives to determine the 
# page size. To run siege with persistent connections set
# the connection directive to keep-alive. (Default close)
# CAUTION: use the keep-aliv

Bug#693896: [siege] siege crashes on FQDN in URL

[Török Edwin]

On 11/23/2012 04:55 AM, Josue Abarca wrote:
> On Wed, Nov 21, 2012 at 04:56:55PM +0200, Török Edwin wrote:
>> Package: siege
>> Version: 2.70-4
>> Severity: normal
> ...
>> Architecture: amd64
>> Kernel:   Linux 3.6.6
>>
>> Debian Release: wheezy/sid
>>   500 unstableftp.ro.debian.org
>> 1 experimentalftp.ro.debian.org
>>
>> --- Package information. ---
>> Depends  (Version) | Installed
>> ==-+-===
>> libc6 (>= 2.7) |
>> libssl1.0.0 (>= 1.0.0) |
> 
> Which versions of libc6 and libssl1.0.0 are you using?
> 
> I am trying to reproduce with the latest versions in sid:
> $ dpkg -l libc6
> ii  libc6:amd642.13-37  amd64
> 
> $ dpkg -l libssl1.0.0
> ii  libssl1.0.0:am 1.0.1c-4 amd64

I've got the same.

> 
> I have been trying, but I have not been able to reproduce the bug.
> 
> Maybe you could try to reproduce it with upstream "2.70" version
> http://www.joedog.org/pub/siege/siege-2.70.tar.gz

It doesn't crash, and valgrind doesn't say anything either.

I've done an 'apt-get source siege', and that doesn't crash either if I 
manually build it
(using a simple ./configure && make).
Maybe it has something to do with the way the Debian package is built (I see 
its using hardening-wrapper).

I've rebuilt the Debian package using pbuilder in a wheezy chroot and a squeeze 
chroot.
None of them crash.

I've just checked again and /usr/bin/siege from the Debian repository still 
crashes.

> 
> In the mean time I'll prepare a debug symbols package for you.

Do you remember what environment/compiler versions where used to build it?
Because apparently simply rebuilding the package makes the crash go away, which 
makes me
believe that it might be due to a compiler bug?

> 
> Here is my output, using your ".siegerc" file:
> 
> $ siege -R .siegerc http://www.jmaslibre.org/index.html
> ** SIEGE 2.70
> ** Preparing 15 concurrent users for battle.
> The server is now under siege...
> Lifting the server siege...  done.
> Transactions:   11 hits
> Availability:   100.00 %
> Elapsed time: 9.32 secs
> Data transferred: 0.00 MB
> Response time:2.21 secs
> Transaction rate: 1.18 trans/sec
> Throughput:   0.00 MB/sec
> Concurrency:  2.61
> Successful transactions:  11
> Failed transactions: 0
> Longest transaction:  5.37
> Shortest transaction: 5.33
>  
> FILE: /var/tmp/siege.log
> You can disable this annoying message by editing
> the .siegerc file in your home directory; change
> the directive 'show-logfile' to false.
> 
> $ siege -R .siegerc http://debian.home.lan/index.html
> ** SIEGE 2.70
> ** Preparing 15 concurrent users for battle.
> The server is now under siege...
> Lifting the server siege...  done.
> Transactions:269 hits
> Availability:100.00 %
> Elapsed time:9.95 secs
> Data transferred:0.04 MB
> Response time:   0.00 secs
> Transaction rate:27.04 trans/sec
> Throughput:  0.00 MB/sec
> Concurrency: 0.11
> Successful transactions: 269
> Failed transactions: 0
> Longest transaction: 0.02
> Shortest transaction:0.00
> 
> FILE: /var/tmp/siege.log
> You can disable this annoying message by editing
> the .siegerc file in your home directory; change
> the directive 'show-logfile' to false.
> 
> 
> Cheers,
> 


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

Bug#655450: [libtool] libltdl linking with -m32 is broken

[Török Edwin]

Package: libtool
Version: 2.4.2-1
Severity: normal

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

libtool transforms -lltdl to  /usr/lib/x86_64-linux-gnu/libltdl.so even if -m32 
is present and then the build fails.
If it would just left -lltdl alone then gcc would've probably found the proper 
lib on its own.
Why does it does libtool try to expand -lltdl

This breaks ClamAV build with -m32 when using system libltdl (i.e. when 
libltdl-dev and ia32-libs are installed).
Everything works when using the embedded libltdl (i.e. libltdl-dev is not 
installed).

I configure ClamAV as:
./configure CFLAGS="-m32 -O2" CXXFLAGS="-m32 -O2"

Here is the link command:
/bin/bash ../libtool  --tag=CC   --mode=link gcc  
-DSEARCH_LIBDIR=\"/usr/local/lib32\" -O2 -m32 -thread-safe -version-info 7:11:1 
-no-undefined -Wl,--version
-script,../../../clamav-devel/libclamav/libclamav.map  -o libclamav.la -rpath /usr/local/lib32 libclamav_la-matcher-ac.lo ... -lltdl -dlopen libclamunrar_iface.la libclamav_nocxx.la 
libclamav_internal_utils.la  -lz -lbz2 -lpthread -lm -ldl
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libclamav_la-matcher-ac.o .libs/libclamav_la-matcher-bm.o  -Wl,--no-whole-archive  /usr/lib/x86_64-linux-gnu/libltdl.so -lz -lbz2 -lpthread -lm -ldl 
 -O2 -m32 -Wl,--version-script -Wl,../../../clamav-devel/libclamav/libclamav.map   -Wl,-soname -Wl,libclamav.so.6 -o .libs/libclamav.so.6.1.11

/usr/lib/x86_64-linux-gnu/libltdl.so: could not read symbols: File in wrong 
format

In Makefile.am there is this:
libclamav_la_LIBADD = @LIBLTDL@ ..
libclamav_la_DEPENDENCIES =  @LTDLDEPS@ ...

And configure.in has this:
LT_CONFIG_LTDL_DIR([libltdl])
LT_INIT([dlopen disable-static])
LTDL_INIT([recursive])
AC_CONFIG_FILES([libltdl/Makefile])

$ ./libtool --version
libtool (GNU libtool) 2.4

But same behaviour if I upgrade libtool to 2.4.2:
$ ./libtool --version
libtool (GNU libtool) 2.4.2

And here is ./libtool --config:

# Which release of libtool.m4 was used?
macro_version=2.4
macro_revision=1.3293

# Whether or not to build static libraries.
build_old_libs=no

# Whether or not to build shared libraries.
build_libtool_libs=yes

# What type of objects to build.
pic_mode=default

# Whether or not to optimize for fast installation.
fast_install=yes

# Shell to use when invoking shell scripts.
SHELL="/bin/bash"

# An echo program that protects backslashes.
ECHO="printf %s\\n"

# The host system.
host_alias=
host=x86_64-unknown-linux-gnu
host_os=linux-gnu

# The build system.
build_alias=
build=x86_64-unknown-linux-gnu
build_os=linux-gnu

# A sed program that does not truncate output.
SED="/bin/sed"

# Sed that helps us avoid accidentally triggering echo(1) options like -n.
Xsed="$SED -e 1s/^X//"

# A grep program that handles long lines.
GREP="/bin/grep"

# An ERE matcher.
EGREP="/bin/grep -E"

# A literal string matcher.
FGREP="/bin/grep -F"

# A BSD- or MS-compatible name lister.
NM="/usr/bin/nm -B"

# Whether we need soft or hard links.
LN_S="ln -s"

# What is the maximum length of a command?
max_cmd_len=3458764513820540925

# Object file suffix (normally "o").
objext=o

# Executable file suffix (normally "").
exeext=

# whether the shell understands "unset".
lt_unset=unset

# turn spaces into newlines.
SP2NL="tr \\040 \\012"

# turn newlines into spaces.
NL2SP="tr \\015\\012 \\040\\040"

# convert $build file names to $host format.
to_host_file_cmd=func_convert_file_noop

# convert $build files to toolchain format.
to_tool_file_cmd=func_convert_file_noop

# An object symbol dumper.
OBJDUMP="objdump"

# Method to check whether dependent libraries are shared objects.
deplibs_check_method="pass_all"

# Command to use when deplibs_check_method = "file_magic".
file_magic_cmd="\$MAGIC_CMD"

# How to find potential files when deplibs_check_method = "file_magic".
file_magic_glob=""

# Find potential files using nocaseglob when deplibs_check_method = 
"file_magic".
want_nocaseglob="no"

# DLL creation program.
DLLTOOL="false"

# Command to associate shared and link libraries.
sharedlib_from_linklib_cmd="printf %s\\n"

# The archiver.
AR="ar"

# Flags to create an archive.
AR_FLAGS="cru"

# How to feed a file listing to the archiver.
archiver_list_spec="@"

# A symbol stripping program.
STRIP="strip"

# Commands used to install an old-style archive.
RANLIB="ranlib"
old_postinstall_cmds="chmod 644 \$oldlib~\$RANLIB \$oldlib"
old_postuninstall_cmds=""

# Whether to use a lock for old archive extraction.
lock_old_archive_extraction=no

# A C compiler.
LTCC="gcc"

# LTCC compiler flags.
LTCFLAGS="-g -O2"

# Take the output of nm and produce a listing of raw symbols and C names.
global_symbol_pipe="sed -n -e 's/^.*[   ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[   
][  ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p' | sed '/ __gnu_lto/d'"

# Transform the output of nm in a proper C declaration.
global_symbol_to_cdecl="sed -n -e 's/^T .* \\(.*\\)\$/extern int \\1();/p' -e 
's/^[ABCDGIRSTW]* .* \\(.*\\)\$/extern char \\1;/p'"

# Trans

Bug#660447: [gnucash] gnucash: cannot retrieve currency quotes anymore

[Török Edwin]

Package: gnucash
Version: 1:2.4.10-1
Severity: normal

--- Please enter the report below this line. ---
Clicking 'Get Quotes' in the Price Editor results in the following error:
"Unable to retrieve quotes for these items:
CURRENCY:RON
CURRENCY:EUR"

If I change the default currency from USD to RON (in Preferences), then 
retrieving the 'RON' currency works,
but 'EUR' doesn't.

Looking at Price Editor these were the last successful attempts:
CURRENCY EUR (Euro):
Currency Date Source   Typ Price Security
RON (New Leu)2010-06-09   user:xfer-dialog 4.155 EUR (Euro)
USD (US Dollar)  2011-10-22   Finance::Quotelast 1.3895 EUR (Euror)

CURRENCY RON (New Leu):
Currency Date Source   Typ PriceSecurity
EUR (Euro)   2012-02-18   user:xfer-dialog 10/41667 RON (New 
Leu)
EUR (Euro)   2012-01-18   user:xfer-dialog  200/853 RON (New 
Leu)

The amounts don't seem to be correct though, the official exchange rate on 
2012-02-18 was
1 EUR = 4.3533 RON
And on 2012-01-18 was:
1 EUR = 4.3497 RON

I've been looking at similar bugreports, but they were about securities, and I 
couldn't figure
how to use gnc-fq-dump to show exchange rates.

$ gnucash -v
gnc.bin-Message: main: binreloc relocation support was disabled at configure 
time.

GnuCash 2.4.10
Built 2012-02-08 from r21973

$ gnucash
gnc.bin-Message: main: binreloc relocation support was disabled at configure 
time.

Found Finance::Quote version 1.17

Official exchange rates can be found here:
http://bnr.ro/nbrfxrates.xml
http://bnr.ro/nbrfxrates10days.xml
http://bnr.ro/files/xml/years/nbrfxrates2011.xml

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.2.6

Debian Release: wheezy/sid
  500 unstableiota.nren.ro
  500 unstableftp.lug.ro

--- Package information. ---
Depends  (Version) | Installed
==-+-
gnucash-common (>= 1:2.4.10-1) | 1:2.4.10-1
guile-1.8-libs | 1.8.8+1-7
libaqbanking33 (>= 4.99.2) | 5.0.22-1
libart-2.0-2   (>= 2.3.18) | 2.3.21-1
libatk1.0-0(>= 1.12.4) | 2.2.0-2
libbonobo2-0   (>= 2.15.0) | 2.24.3-1
libbonoboui2-0 (>= 2.15.1) | 2.24.3-1
libc6 (>= 2.4) | 2.13-26
libcairo2   (>= 1.2.4) | 1.10.2-6.2
libdbi1 (>= 0.8.4) | 0.8.4-5.1
libfontconfig1  (>= 2.8.0) | 2.8.0-3.1
libfreetype6(>= 2.2.1) | 2.4.8-1
libgconf2-4(>= 2.31.1) | 3.2.3-1
libgdk-pixbuf2.0-0 (>= 2.22.0) | 2.24.1-1
libglade2-0   (>= 1:2.6.1) | 1:2.6.4-1
libglib2.0-0   (>= 2.30.0) | 2.30.2-6
libgmp10   | 2:5.0.4+dfsg-1
libgnome-keyring0  (>= 2.20.3) | 3.2.2-2
libgnome2-0(>= 2.17.3) | 2.32.1-2
libgnomecanvas2-0  (>= 2.11.1) | 2.30.3-1
libgnomeui-0   (>= 2.22.0) | 2.24.5-2
libgnomevfs2-0  (>= 1:2.17.90) | 1:2.24.4-1
libgoffice-0.8-8(>= 0.8.8) | 0.8.17-1
libgtk2.0-0(>= 2.12.0) | 2.24.9-2
libgwengui-gtk2-0 (>= 3.99.16) | 4.3.1-1
libgwenhywfar60(>= 3.99.1) | 4.3.1-1
libice6   (>= 1:1.0.0) | 2:1.0.7-2
libjavascriptcoregtk-1.0-0  (>= 1.5.1) | 1.6.3-1
libktoblzcheck1c2a   (>= 1.19) | 1.37-1
libltdl7(>= 2.4.2) | 2.4.2-1
libofx4| 1:0.9.4-2
liborbit2   (>= 1:2.14.10) | 1:2.14.19-0.1
libpango1.0-0  (>= 1.14.0) | 1.29.4-2
libpopt0 (>= 1.14) | 1.16-3
libsm6 | 2:1.2.0-2
libsoup2.4-1(>= 2.4.0) | 2.36.1-1
libwebkitgtk-1.0-0 (>= 1.3.10) | 1.6.3-1
libx11-6   | 2:1.4.4-4
libxml2 (>= 2.7.4) | 2.7.8.dfsg-7
zlib1g(>= 1:1.1.4) | 1:1.2.6.dfsg-1
perl   | 5.14.2-7
slib   | 3b1-3.1
guile-1.8  (>= 1.8.8+1-4~) | 1.8.8+1-7
libfinance-quote-perl  | 1.17+git20110918-1
libwww-perl| 6.03-1
libhtml-tree-perl  | 4.2-1
libhtml-tableextract-perl  | 2.11-1
libcrypt-ssleay-perl   | 0.58-1
libdate-manip-perl | 6.30-1


Recommends(Version) | Installed
===-+-===
gnucash-docs| 2.4.1-3
yelp  

Bug#680378: [ia32-libs-i386] ia32-libs uninstallable: ia32-libs-i386 missing and buildd not building

[Török Edwin]

Package: ia32-libs-i386
Version: 20120701
Severity: normal

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

ia32-libs is 20120701, but ia32-libs-i386 is still 20120616, and as such 
ia32-libs is uninstallable
(unupgradable) now.

Looking at the buildd it looks like it doesn't want to build it (could be 
wrong, not very familiary with how the buildd works):
https://buildd.debian.org/status/architecture.php?a=i386&suite=sid
Auto-Not-For-Us: 78: [...] , ia32-libs, [...]

Also there is something that says ia32-libs is amd64 and ia64 only here:
https://buildd.debian.org/quinn-diff/sid/Packages-arch-specific

ia32-libs-i386 doesn't show up on the buildd at all:
https://buildd.debian.org/status/package.php?p=ia32-libs-i386&suite=sid

Apparently ia32-libs-i386 is in the archive because it got uploaded directly as 
a binary (not from a buildd):
http://packages.qa.debian.org/i/ia32-libs/news/20120630T094734Z.html

But the latest ia32-libs upload didn't include the ia32-libs-i386 binary in the 
upload:
http://packages.qa.debian.org/i/ia32-libs/news/20120704T103209Z.html

Could you please fix the buildd's configuration to build the package, or upload 
the prebuilt binary?

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

The following packages have unmet dependencies:
 ia32-libs : Depends: ia32-libs-i386

$ apt-cache policy ia32-libs
ia32-libs:
  Installed: 20120102
  Candidate: 20120701
  Version table:
 20120701 0
500 http://iota.nren.ro/debian/ unstable/main amd64 Packages
500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
 *** 20120102 0
500 http://iota.nren.ro/debian/ testing/main amd64 Packages
100 /var/lib/dpkg/status

$ apt-cache policy ia32-libs-i386
ia32-libs-i386:i386:
  Installed: (none)
  Candidate: 20120616
  Version table:
 20120616 0
500 http://iota.nren.ro/debian/ unstable/main i386 Packages
500 http://ftp.de.debian.org/debian/ unstable/main i386 Packages


Thanks,
--Edwin

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.5.0-rc4

Debian Release: wheezy/sid
  500 unstableiota.nren.ro
  500 unstableftp.de.debian.org
  500 testing iota.nren.ro

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.






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

Bug#680378: [buildd.debian.org] ia32-libs-* entries in Packages-arch-specific still wrong

[Török Edwin]

Package: buildd.debian.org

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

FWIW ia32-libs-gtk is still not installable.
ia32-libs was installable for quite some time now (thanks!), although its entry
in Packages-arch-specific was still not updated.

Will this be fixed for wheezy?

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.5.0

Debian Release: wheezy/sid
  500 unstableiota.nren.ro
  500 unstableftp.de.debian.org
  500 testing iota.nren.ro

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#705426: [pulseaudio] slow KDE autostart: /etc/xdg/pulseaudio.desktop and pulseaudio-kde.desktop duplicate

[Török Edwin]

Package: pulseaudio
Version: 2.0-6
Severity: normal

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

Upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=58758

There are two pulseaudio autostart files in /etc/xdg/autostart:
pulseaudio.desktop and pulseaudio-kde.desktop, and they both try to
start causing noticable delay of autostarted applications on KDE login
(probably until some timeout is reached).

Steps to reproduce:
1. Add Icedove, Pidgin, and Gkrellm to autostart (or some other
applications):
$ ls $HOME/.config/autostart
GKrellM System Monitor.desktop Pidgin Internet Messenger.desktop
Icedove Mail⁄News.desktop
2. Logout from KDE, and login again
3. Wait until splash screen disappears

Expected behaviour:
4. The autostarted applications should start now

Actual behaviour:
4. There is a noticable delay of several seconds (haven't measured
exactly how many)
5. Then the autostarted applications start

Solution:
Add 'NotShowIn=KDE;' to /etc/xdg/autostart/pulseaudio.desktop
(or remove it, but that'd break Gnome, so don't)

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.8.7

Debian Release: 7.0
  500 unstableftp.ro.debian.org
  500 testing security.debian.org
  500 testing ftp.ro.debian.org
1 experimentalftp.ro.debian.org

--- Package information. ---
Depends   (Version) | Installed
===-+-===
libasound2(>= 1.0.24.1) |
libc6  (>= 2.9) |
libcap2   (>= 2.10) |
libdbus-1-3  (>= 1.1.1) |
libfftw3-3  |
libgcc1(>= 1:4.1.1) |
libice6(>= 1:1.0.0) |
libltdl7 (>= 2.4.2) |
liborc-0.4-0  (>= 1:0.4.16) |
libpulse0 (= 2.0-6) |
libsamplerate0   (>= 0.1.7) |
libsm6  |
libsndfile1 (>= 1.0.20) |
libspeexdsp1 (>= 1.2~beta3.2-1) |
libstdc++6   (>= 4.1.1) |
libsystemd-daemon0  (>= 31) |
libsystemd-login0   (>= 31) |
libtdb1  (>= 1.2.7+git20101214) |
libudev0   (>= 146) |
libwebrtc-audio-processing-0|
libx11-6|
libx11-xcb1 |
libxcb1 |
libxtst6|
adduser |
lsb-base(>= 3.2-13) |
consolekit  |
udev   (>= 143) |
libasound2-plugins  |


Recommends(Version) | Installed
===-+-===
pulseaudio-module-x11   | 2.0-6
gstreamer0.10-pulseaudio| 0.10.31-3+nmu1
rtkit   | 0.10-2


Suggests  (Version) | Installed
===-+-===
pulseaudio-utils| 2.0-6
pavumeter   |
pavucontrol |
paman   |
paprefs |


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

Bug#711206: [perl] double free in Digest::SHA

[Török Edwin]

Package: perl
Version: 5.14.2-21
Severity: normal

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

I noticed perl crashing when pressing Ctrl-C on the vanityhash script.
It is hard to reproduce apparently it depends a lot timing,  I managed
to reproduce it only 3 times while writing this bugreport (out of ~30).

$ ./vanityhash -b 32 -w 6 -d sha1 08b5124c447f = 5.14.2-21) | 5.14.2-21
libbz2-1.0  | 1.0.6-4
libc6 (>= 2.11) |
libdb5.1|
libgdbm3 (>= 1.8.3) |
zlib1g   (>= 1:1.2.3.3) |


Recommends  (Version) | Installed
=-+-===
netbase   | 5.1


Suggests(Version) | Installed
=-+-===
perl-doc  |
libterm-readline-gnu-perl |
 OR libterm-readline-perl-perl| 1.0303-1
make  | 3.81-8.2




#!/usr/bin/perl


# vanityhash, a hex hash fragment creation tool
# Copyright (C) 2010 Ryan Finnie 
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
# 02110-1301, USA.


my $VERSION = '1.1';

use strict;
use warnings;
use Digest;
use Getopt::Long;
use Pod::Usage;
use Time::HiRes qw/time/;
use Socket;
use IO::Handle;
use IO::Select;
use POSIX ":sys_wait_h";

my $opt_find;
my $opt_bits = 24;
my $opt_findpos = 0;
my $opt_anypos;
my $opt_progressint = 5;
my $opt_workers = 1;
my $opt_digesttype = "md5";
my $opt_append;
my $opt_quiet;
my $opt_help;

Getopt::Long::Configure("bundling");
my($result) = GetOptions(
  'bits|b=i' => \$opt_bits,
  'position|p=i' => \$opt_findpos,
  'any-position|y' => \$opt_anypos,
  'progress|s=f' => \$opt_progressint,
  'workers|w=i' => \$opt_workers,
  'digest|d=s' => \$opt_digesttype,
  'append|a' => \$opt_append,
  'quiet|q' => \$opt_quiet,
  'help|?' => \$opt_help,
);

if((scalar @ARGV == 0) || $opt_help) {
  print STDERR "vanityhash version $VERSION\n";
  print STDERR "Copyright (C) 2010 Ryan Finnie \n";
  print STDERR "\n";
  pod2usage(2);
}

$opt_find = $ARGV[0];
unless($opt_find =~ /^[0-9A-Fa-f]+$/) {
  die("Pattern must be specified as hex digits.\n");
}

if(($opt_bits < 1) || ($opt_bits > 64)) {
  die("Search space must be between 1 and 64 bits, inclusive.\n");
}

my $packtype;
if($opt_bits > 32) {
  $packtype = 'Q';
  eval {
my $testpack = pack($packtype, 0);
  };
  die("Search spaces greater than 32 bits are not supported on this 
platform.\n") if $@;
} elsif($opt_bits > 16) {
  $packtype = 'L';
  eval {
my $testpack = pack($packtype, 0);
  };
  # Running this in real mode DOS, perhaps?
  die("Search spaces greater than 16 bits are not supported on this 
platform.\n") if $@;
} elsif($opt_bits > 8) {
  $packtype = 'S';
  eval {
my $testpack = pack($packtype, 0);
  };
  # Apple II?
  die("Search spaces greater than 8 bits are not supported on this 
platform.\n") if $@;
} else {
  $packtype = 'C';
}

# This is an arbitrary restriction to protect users from themselves and 
# exhaust resources.  If you happen to have a system with more than 64 
# hardware threads, manually disable this check.  Also, could I borrow 
# the system?
if(($opt_workers < 1) || ($opt_workers > 64)) {
  die("Workers must be between 1 and 64, inclusive.\n");
}

if($opt_findpos < 0) {
  die("Pattern position must be 0 or greater.\n");
}

# All digest operations are lowercase.
$opt_find = lc($opt_find);

# Allowed: md2 md4 md5 sha1alt sha* crc*
my(@digestarray, $digestdisp);
if($opt_digesttype eq "md5") {
  $digestdisp = "MD5";
  @digestarray = ("MD5");
} elsif($opt_digesttype eq "md4") {
  $digestdisp = "MD4";
  @digestarray = ("MD4");
} elsif($opt_digesttype eq "md2") {
  $digestdisp = "MD2";
  @digestarray = ("MD2");
} elsif($opt_digesttype eq "sha1alt") {
  $digestdisp = "SHA1";
  @digestarray = ("SHA1");
} elsif($opt_digesttype =~ /^sha(\d+)$/) {
  $digestdisp = "SHA$1";
  @digestarray = ("SHA", $1);
} elsif($opt_digesttype =~ /^crc(.*?)$/) {
  $digestdisp = uc("CRC$1");
  @digestarray = ("CRC", (type => lc("crc$1")));
} else {
  die(sprintf("Unknown digest type: %s\n", $opt_digesttype));
}

my $findlen = length($opt_find);
my $every = 10 * $opt_

Bug#703229: [libasan0] libasan0: /usr/bin/ld.bfd.real: cannot find libasan_preinit.o: No such file or directory

[Török Edwin]

Package: libasan0
Version: 4.8-20130315-1
Severity: normal

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

GCC-4.8's(from experimental) -fsanitize=address flag is not working:

$ gcc-4.8 -fsanitize=address test.c
/usr/bin/ld.bfd.real: cannot find libasan_preinit.o: No such file or directory
collect2: error: ld returned 1 exit status


$ apt-cache policy libasan0
libasan0:
  Installed: 4.8-20130315-1
  Candidate: 4.8-20130315-1
  Version table:
 *** 4.8-20130315-1 0
  1 http://ftp.ro.debian.org/debian/ experimental/main amd64 Packages
100 /var/lib/dpkg/status
$ dpkg -L libasan0
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libasan.so.0.0.0
/usr/share
/usr/share/doc
/usr/lib/x86_64-linux-gnu/libasan.so.0
/usr/share/doc/libasan0
--- System information. ---
Architecture: amd64
Kernel:   Linux 3.8.3

Debian Release: 7.0
  500 unstableftp.ro.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.ro.debian.org

--- Package information. ---
Depends   (Version) | Installed
===-+-===
gcc-4.8-base (= 4.8-20130315-1) |
libc6(>= 2.2.5) |
libgcc1(>= 1:4.1.1) |
libstdc++6   (>= 4.1.1) |


Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#703230: [gcc-4.8] gcc-4.8: -fsanitize=thread requires -fPIC too

[Török Edwin]

Package: gcc-4.8
Version: 4.8-20130315-1
Severity: normal

--- Please enter the report below this line. ---
GCC says that -pie or -shared is needed to use -fsanitize=thread, but that is 
not enough on amd64:
$ /usr/bin/gcc-4.8 -fsanitize=thread test.c -pie
/usr/bin/ld.bfd.real: /tmp/ccBEgPXP.o: relocation R_X86_64_PC32 against 
undefined symbol `__tsan_func_entry' can not be used when making a shared 
object; recompile with -fPIC
/usr/bin/ld.bfd.real: final link failed: Bad value
collect2: error: ld returned 1 exit status

-fPIC is needed too:
$ /usr/bin/gcc-4.8 -fsanitize=thread test.c -pie -fPIC


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.8.3

Debian Release: 7.0
  500 unstableftp.ro.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.ro.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-===
gcc-4.8-base   (= 4.8-20130315-1) |
cpp-4.8(= 4.8-20130315-1) |
binutils(>= 2.22) |
libgcc-4.8-dev (= 4.8-20130315-1) |
libc6   (>= 2.14) |
libcloog-isl4   (>= 0.17) |
libgmp10  |
libisl10(>= 0.10) |
libmpc2   |
libmpfr4   (>= 3.1.1) |
zlib1g   (>= 1:1.1.4) |


Recommends   (Version) | Installed
==-+-
libc6-dev  (>= 2.13-5) |


Suggests(Version) | Installed
=-+-==
gcc-4.8-multilib  |
libmudflap0-4.8-dev(= 4.8-20130315-1) |
gcc-4.8-doc  (>= 4.8) |
gcc-4.8-locales  (>= 4.8) |
libgcc1-dbg (>= 1:4.8-20130315-1) | 1:4.8-20130315-1
libgomp1-dbg  (>= 4.8-20130315-1) |
libitm1-dbg   (>= 4.8-20130315-1) |
libatomic1-dbg(>= 4.8-20130315-1) |
libasan0-dbg  (>= 4.8-20130315-1) |
libtsan0-dbg  (>= 4.8-20130315-1) |
libbacktrace1-dbg (>= 4.8-20130315-1) |
libquadmath0-dbg  (>= 4.8-20130315-1) |
libmudflap0-dbg   (>= 4.8-20130315-1) |
binutils-gold   (>= 2.22) | 2.21.52.20110707-1


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

Bug#703230: [gcc-4.8] gcc-4.8: -fsanitize=thread requires -fPIC too

[Török Edwin]

On 03/19/2013 12:07 AM, Matthias Klose wrote:
> Am 17.03.2013 04:03, schrieb Török Edwin:
>> GCC says that -pie or -shared is needed to use -fsanitize=thread
> 
> where?
> 
> 

In the error message when you use just -fsanitize=thread:
$ gcc-4.8 -fsanitize=thread x.c
gcc-4.8.real: error: -fsanitize=thread linking must be done with -pie or -shared

It should probably mention -fPIC on amd64, as it doesn't work with just -pie.

The manual doesn't mention this either,  but thats an upstream problem as 
Debian didn't package that yet.

Best regards,
--Edwin


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

Bug#703230: [gcc-4.8] gcc-4.8: -fsanitize=thread requires -fPIC too

[Török Edwin]

forwarded 703230 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56682
thanks


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

Bug#708105: [buildd.debian.org] binNMUs break multiarch lib packages

[Török Edwin]

Package: buildd.debian.org
Severity: normal

--- Please enter the report below this line. ---
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708055 for a recent 
example.

diff -u 1/changelog.Debian 2/changelog.Debian
--- 1/changelog.Debian  2013-05-12 12:40:00.0 +0300
+++ 2/changelog.Debian  2013-05-12 12:36:00.0 +0300
@@ -1,9 +1,9 @@
 mesa (8.0.5-4+b1) sid; urgency=low

-  * Binary-only non-maintainer upload for amd64; no source changes.
+  * Binary-only non-maintainer upload for i386; no source changes.
   * Rebuild against libffi6

- -- amd64 Builddd Daemon (barber)   Sun,
12 May 2013 09:40:10 +
+ -- i386 Build Daemon (murphy)   Sun, 12
May 2013 09:36:04 +

Since wheezy is out a solution should be implemented for this IMHO, otherwise
it'll just make all upcoming transitions break packages on a binNMU.

Please drop the architecture and buildd names from binNMU uploads: the buildd
could sign the .deb packages to let people find out which builder processed a
binNMU.

Or you  could put the binNMU into a separate file as suggested here:
http://lists.debian.org/debian-dpkg/2012/07/msg00024.html

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.9.1

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org
  500 stable  security.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.ro.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#702865: [colord] colord: doesn't start on boot

[Török Edwin]

Package: colord
Version: 0.1.21-4
Severity: normal

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

colord doesn't have an /etc/init.d/ entry and as such it doesn't start on boot.

colord has some entries for systemd, but I don't use systemd:
/lib/systemd/system/colord.service
/lib/systemd/system/colord-sane.service


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.8.1

Debian Release: 7.0
  500 unstableftp.ro.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.ro.debian.org

--- Package information. ---
Depends   (Version) | Installed
===-+-==
libc6  (>= 2.4) |
libcolord1  (>= 0.1.20) |
libdbus-1-3  (>= 1.0.2) |
libglib2.0-0(>= 2.31.8) |
libgudev-1.0-0 (>= 146) |
libgusb2 (>= 0.1.3) |
liblcms2-2  |
libpolkit-gobject-1-0 (>= 0.99) |
libsane   (>= 1.0.11-3) |
libsqlite3-0 (>= 3.5.9) |
libusb-1.0-0   (>= 2:1.0.8) |
adduser |
acl |
policykit-1  (>= 0.103) |


Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#702955: caused by .gtkrc-2.0 change

[Török Edwin]

More info about the crash:

If I move ~/.gtkrc-2.0 away then dispcalGUI no longer crashes.

It looks like ~/.gtkrc-2.0 needs to have this content to trigger the crash:
include "/usr/share/themes/QtCurve/gtk-2.0/gtkrc"
include "/etc/gtk-2.0/gtkrc"
gtk-theme-name="QtCurve"

If I remove the QtCurve include and gtk-theme-name it no longer crashes!

Hope this helps track down the bug.

--Edwin


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

Bug#575449: -O* needs to be passed to linker too

[Török Edwin]

On 2010-03-26 21:11, Ralf Wildenhues wrote:
> * Török Edwin wrote on Fri, Mar 26, 2010 at 12:33:14PM CET:
>> In fact -O* flags need to be passed to the linker too for LTO to do any
>> optimizations at all.
> 
> Yup.

There's also a caveat (or rather compiler bug): using one -O level when
compiling, and another when linking doesn't really work:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42402

> 
>> So if I call gcc -O2 -flto x.o y.o, libtool will need to pass both -O2
>> and -flto. And of course any -f* -m* flags that affect code generation.
> 
> -m* is passed through by libtool.

Ok, but I think -f* should be passed too, they affect code generation as
well, especially -fPIC.

Apparently even if you compile ALL the individual files with -fPIC,
you need to pass -fPIC on the link command-line too, otherwise you get a
failure when building shared libs (that relocation error message that
tells you to use -fPIC).
I consider this rather a gcc bug (it should know that -shared needs
-fPIC for -flto), see here #575451.

Or do you think libtool should handle this?

> 
>> Also -fuser-linker-plugin needs to be passed on by libtool.
> 
> Yes, I gues libtool should support -fuse-linker-plugin too.

Ok.

> 
>> In fact for LTO I think it'd make sense to pass all of CFLAGS/CXXFLAGS
>> to the linker, since they affect code generation at link time now.
>> Or document the fact that you need to export LDFLAGS="$CFLAGS" if you
>> want LTO to work.
> 
> When you use Automake to create your makefiles, then $(CFLAGS) is passed
> on the C linker command line already.  Using LDFLAGS=$CFLAGS will not
> buy you anything.  This issue is purely about which flags libtool passes
> through to the compiler driver.

Yeah nevermind LDFLAGS, I got confused by libtool stripping the flags.

BTW I'm using a simple hack for now, I set
new_inherited_linker_flags="-flto -O2", and that allows me to test LTO.

> 
> If you mix several languages in your package, you may need to add -flto
> to all per-language flags.

Yes.

Best regards,
--Edwin



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

Bug#575449: libtool should support gcc's -flto

[Török Edwin]

On 2010-03-26 21:07, Ralf Wildenhues wrote:
> tags +upstream
> thanks
> 
> Hello Török,
> 
> thanks for the report.
> 
> * Török Edwin wrote on Thu, Mar 25, 2010 at 10:24:08PM CET:
>> Currently libtool strips -flto when called for linking which is wrong.
>> It should pass -flto to gcc, since its both a compile-time and a link-time 
>> flag.
> 
> I agree.  There has been a similar request for another compiler
> recently, too, let's address them both, upstream.

I'm not subscribed to the upstream ML, but when you have any patches
you'd like me to test, please send me an e-mail.

> 
>> Actually I don't know why libtool strips any flags at all. If I pass a flag
>> at compile time, and libtool happily passes it along (such as -flto here),
>> why does it strip it at link time?
> 
> FWIW, libtool only strips flags when creating shared libraries, not when
> creating programs.

Didn't know that, since I didn't get that far (build stopped when shared
lib failed to build). Good to know though.

> 
> Many flags need changed libtool semantics, when passed through.
> For example, just passing through -flto without further changes
> let me find one GCC bug

Maybe you hit this bug? (mixing -O flags)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42402

> and half a dozen Libtool testsuite failures
> and several places where libtool needs to be changed.  It's simply
> more robust to strip unknown flags.

Fair enough.

Could libtool give a warning when it strips a flag though?
Not everyone inspects the link command-line passed to gcc, so they may
think they used an optimization flag (other than -O), but in reality
libtool stripped it.

Best regards,
--Edwin



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

Bug#575449: -O* needs to be passed to linker too

[Török Edwin]

On 2010-03-26 22:21, Ralf Wildenhues wrote:
> * Török Edwin wrote on Fri, Mar 26, 2010 at 08:45:44PM CET:
> 
> You should be able to use ./configure CC='gcc -flto -O2' too.

Ah I've completely forgotten about that possibility, I used that when
testing LLVM's LTO support (http://llvm.org/docs/GoldPlugin.html).
Which uses yet another flag .. -use-gold-plugin.

Best regards,
--Edwin



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

Bug#575748: automake: distcheck broken if build crosses midnight

[Török Edwin]

Package: automake
Version: 1:1.11.1-1
Severity: normal

Automake's 'make distcheck' gives a failure if the 'make distcheck'
crosses midnight (i.e. it begins on day X, and ends at day X+1),
since it thinks distclean failed:

make[2]: Leaving directory 
`/var/lib/buildbot/clambb/slave1/distcheck/build/clamav-devel-20100328/_build'
rm -f config.status config.cache config.log configure.lineno 
config.status.lineno
rm -f Makefile
ERROR: files left in build directory after distclean:
./clamav-devel-20100329.tar.gz
./clamav-devel-20100329.tar.bz2
make[1]: *** [distcleancheck] Error 1

The build started on 2010-03-28 at 23:59:54, and ended at 2010-03-29 at
00:04:02.
Now distcheck expects to find a clamav-devel-20100328.tar.gz file after 'make
distcheck' but it finds a clamav-devel-20100329.tar.gz and fails.

This is a rare condition (build crossing midnight), but it causes a buildbot
to consider a build failed when it shouldn't.

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

Kernel: Linux 2.6.33-00175-g2d1299a0 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages automake depends on:
ii  autoconf  2.65-4 automatic configure script builder
ii  autotools-dev 20100122.1 Update infrastructure for config.{
ii  dpkg  1.15.5.6   Debian package management system
ii  install-info  4.13a.dfsg.1-5 Manage installed documentation in 

automake recommends no packages.

automake 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#576142: RFP: klee -- KLEE is a symbolic virtual machine built on top of the LLVM compiler infrastructure

[Török Edwin]

Package: wnpp
Severity: wishlist


* Package name: klee
  Version : 2.7
  Upstream Author : Cristian Cadar , Daniel Dunbar 
, Dawson Engler
* URL : http://klee.llvm.org/
* License : UIUC
  Programming Lang: C, C++
  Description : KLEE is a symbolic virtual machine built on top of the LLVM 
compiler infrastructure

KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex 
Systems Programs
KLEE is a symbolic virtual machine built on top of the LLVM compiler 
infrastructure, and available under the UIUC open source license.
For more information on what KLEE is and what it can do, see the OSDI 2008 
paper. [http://llvm.org/pubs/2008-12-OSDI-KLEE.html]
If you are interested in trying it yourself, please see Getting Started.
[http://klee.llvm.org/GetStarted.html]



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

Bug#576392: iceweasel: firefox symlink gone

[Török Edwin]

Package: iceweasel
Version: 3.5.9-2
Severity: normal

After today's upgrade of iceweasel the firefox command is gone:
bash: firefox: command not found

If there was a package called firefox that install the firefox command I'd be
happy to install it, but there isn't:
# apt-get install firefox
...
Package firefox is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package firefox has no installation candidate

I think Debian should ship a firefox command, even its just a symlink to
iceweasel, since people who are new to Debian won't know what iceweasel is, and
that they have to install that instead of firefox.

How about an /etc/alternatives for firefox? It defaults to iceweasel, and if the
real firefox is ever distributable as a package, then it'll switch to that.

IMHO just removing the firefox symlink like this is unacceptable for the
release.

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Status: enabled

Name: Cookie Exporter
Location: ${PROFILE_EXTENSIONS}/cookieexpor...@krk
Status: enabled

Name: Default
Location: /usr/lib/iceweasel/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: Firebug
Location: ${PROFILE_EXTENSIONS}/fire...@software.joehewitt.com
Status: enabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
Status: enabled

Name: Page Speed
Location: ${PROFILE_EXTENSIONS}/{e3f6c2cc-d8db-498c-af6c-499fb211db97}
Status: enabled

Name: Tamper Data
Location: ${PROFILE_EXTENSIONS}/{9c51bd27-6ed8-4000-a2bf-36cb95c0c947}
Status: enabled

-- Plugins information
Name: Skype Buttons for Kopete
Location: /usr/lib/mozilla/plugins/libskypebuttons.so
Package: kopete
Status: enabled

Name: VLC Multimedia Plug-in
Location: /usr/lib/mozilla/plugins/libvlcplugin.so
Package: mozilla-plugin-vlc
Status: enabled


-- Addons package information
ii  iceweasel  3.5.9-2Web browser based on Firefox
ii  kopete 4:4.3.4-2  instant messenger for KDE 4
ii  mozilla-plugin 1.0.5-2multimedia plugin for web browsers based on 

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

Kernel: Linux 2.6.33-00175-g2d1299a0 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages iceweasel depends on:
ii  debianutils   3.2.2  Miscellaneous utilities specific t
ii  fontconfig2.8.0-2generic font configuration library
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib
ii  libglib2.0-0  2.24.0-1   The GLib library of C routines
ii  libgtk2.0-0   2.18.7-1   The GTK+ graphical user interface 
ii  libnspr4-0d   4.8.4-1NetScape Portable Runtime Library
ii  libstdc++64.5-20100227-1 The GNU Standard C++ Library v3
ii  procps1:3.2.8-8  /proc file system utilities
ii  psmisc22.10-1utilities that use the proc file s
ii  xulrunner-1.9.1   1.9.1.9-3  XUL + XPCOM application runner

iceweasel recommends no packages.

Versions of packages iceweasel suggests:
ii  latex-xft-fonts1.6.5-1   TrueType versions of some TeX font
ii  libgssapi-krb5-2   1.8+dfsg~alpha1-7 MIT Kerberos runtime libraries - k
pn  mozplugger (no description available)
ii  ttf-lyx1.6.5-1   TrueType versions of some TeX font
pn  ttf-mathematica4.1 (no description available)
ii  xfonts-mathml  4 Type1 Symbol font for MathML
pn  xprint (no description available)

Versions of packages xulrunner-1.9.1 depends on:
ii  libasound2  1.0.22-2 shared library for ALSA applicatio
ii  libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii  libbz2-1.0  1.0.5-4  high-quality block-sorting file co
ii  libc6   2.10.2-6 Embedded GNU C Library: Shared lib
ii  libcairo2   1.8.10-3 The Cairo 2D vector graphics libra
ii  libdbus-1-3 1.2.20-2 simple interprocess messaging syst
ii  libfontconfig1  2.8.0-2  generic font configuration library
ii  libfreetype62.3.11-1 FreeType 2 font engine, shared lib
ii  libgcc1 1:4.5-20100227-1 GCC support library
ii  libglib2.0-02.24.0-1 The GLib library of C routines
ii  libgtk2.0-0 2.18.7-1 The GTK+ graphical user interface 
ii  libhunspell-1.2-0   1.2.8-6  spell checker and morphological

Bug#629399: [linux-headers-2.6.38] not installable: missing linux-kbuild-2.6.38 from squeeze-backports

[Török Edwin]

Package: linux-headers-2.6.38
Version: 2.6.38-3~bpo60+1
Severity: normal

--- Please enter the report below this line. ---
linux-kbuild-2.6.38 is missing from squeeze-backports, and this prevents
linux-headers-2.6.38 from being installed:

$ apt-get install linux-headers-2.6.38-bpo.2-all-amd64
linux-headers-2.6.38-bpo.2-amd64 -t squeeze-backports
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 linux-headers-2.6.38-bpo.2-amd64 : Depends: linux-kbuild-2.6.38 but it
is not installable

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.0-rc1

Debian Release: wheezy/sid
  500 unstableftp.lug.ro
  500 testing security.debian.org
  500 testing ftp.ro.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.lug.ro

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.






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

Bug#629400: [linux-headers-2.6.38-bpo.2-amd64] not installable: missing linux-kbuild-2.6.38 from squeeze-backports

[Török Edwin]

Package: linux-headers-2.6.38-bpo.2-amd64
Version: 2.6.38-3~bpo60+1
Severity: normal

--- Please enter the report below this line. ---
linux-kbuild-2.6.38 is missing from squeeze-backports, and this prevents
linux-headers-2.6.38 from being installed:

$ apt-get install linux-headers-2.6.38-bpo.2-all-amd64
linux-headers-2.6.38-bpo.2-amd64 -t squeeze-backports
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 linux-headers-2.6.38-bpo.2-amd64 : Depends: linux-kbuild-2.6.38 but it
is not installable

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.0-rc1

Debian Release: wheezy/sid
  500 unstableftp.lug.ro
  500 testing security.debian.org
  500 testing ftp.ro.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.lug.ro

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.






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

Bug#629844: [vim-syntax-go] wrong dir for files: vim-addons won't install it

[Török Edwin]

Package: vim-syntax-go
Version: 1:57.1-2
Severity: normal

--- Please enter the report below this line. ---
$ vim-addons install go-syntax  -v
Warning: ignoring 'go-syntax' which is missing source files
- /usr/share/vim/addons/ftplugin/go/import.vim
- /usr/share/vim/addons/ftplugin/go/fmt.vim

Workaround:
# mkdir /usr/share/vim/addons/ftplugin/go
# mv /usr/share/vim/addons/ftplugin/fmt.vim
/usr/share/vim/addons/ftplugin/go
# mv /usr/share/vim/addons/ftplugin/import.vim
/usr/share/vim/addons/ftplugin/go

This should be fixed in the package though, as it is the package doesn't
work.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.0-rc2

Debian Release: wheezy/sid
  500 unstableftp.lug.ro
  500 testing security.debian.org
  500 testing ftp.ro.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.lug.ro

--- Package information. ---
Depends  (Version) | Installed
==-+-===
vim| 2:7.3.154+hg~74503f6ee649-2+b1


Recommends (Version) | Installed
-+-===
vim-addon-manager| 0.4.3


Suggests   (Version) | Installed
-+-===
golang-go| 1:57.1-2







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

Bug#637998: [git] git prune: dumps core when run on Linux repository

[Török Edwin]

Package: git
Version: 1:1.7.5.4-1
Severity: normal

--- Please enter the report below this line. ---
When I run 'git prune' on the Linux repository I get a coredump:.

See stacktrace from the coredump at end of this bugreport.
I couldn't find a git-dbg package though to get a more useful stacktrace.
Would it be possible to build a git-dbg package too in the future?

Also if I upgrade to git 1.7.6 from experimental the crash is gone,
so this is probably a bug that is already fixed there.

edwin@debian:~/builds/linux-2.6$ git remote -v
origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 (fetch)
origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 (push)
stable  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-3.0.y.git 
(fetch)
stable  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-3.0.y.git 
(push)
edwin@debian:~/builds/linux-2.6$ git prune
Segmentation fault (core dumped)
edwin@debian:~/builds/linux-2.6$ git --version
git version 1.7.5.4

It dumps core everytime.

Interestingly a VM running on same machine doesn't dump core when runnning git 
prune,
so this might be a regression from 1.7.5.3 (or perhaps the directories don't 
have identical
content despite being clones of eachother):
edwin@debian2:~/linux-2.6$ git remote -v
origin  192.168.1.101:builds/linux-2.6 (fetch)
origin  192.168.1.101:builds/linux-2.6 (push)
edwin@debian2:~/linux-2.6$ git --version
git version 1.7.5.3

I upgraded to 1.7.6 from experimental, and that one doesn't crash.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libz.so.1...Reading symbols from 
/usr/lib/debug/usr/lib/libz.so.1.2.5...done.
done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols 
from /usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.13.so...done.
done.
Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from 
/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.13.so...done.
done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `git prune'.
Program terminated with signal 11, Segmentation fault.
#0  0x00498aa9 in ?? ()
(gdb) bt
#0  0x00498aa9 in ?? ()
#1  0x004a269f in ?? ()
#2  0x004a26b2 in ?? ()
#3  0x004a26b2 in ?? ()
#4  0x004a28bb in ?? ()
#5  0x0044ac90 in ?? ()
#6  0x00405364 in ?? ()
#7  0x0040486b in ?? ()
#8  0x003c7141eead in __libc_start_main (main=, 
argc=, ubp_av=,
init=, fini=, rtld_fini=, stack_end=0x7fff5e0609d8) at libc-start.c:228
#9  0x00404c6d in ?? ()
#10 0x7fff5e0609d8 in ?? ()
#11 0x001c in ?? ()
#12 0x0002 in ?? ()
#13 0x7fff5e062562 in ?? ()
#14 0x in ?? ()



--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.1

Debian Release: wheezy/sid
  500 unstableftp.ro.debian.org
  500 unstableftp.lug.ro
  500 testing security.debian.org
  500 testing ftp.ro.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.lug.ro

--- Package information. ---
Depends(Version) | Installed
-+-=
libc6 (>= 2.3.4) | 2.13-14
libcurl3-gnutls(>= 7.16.2-1) | 7.21.6-3
libexpat1(>= 1.95.8) | 2.0.1-7
zlib1g  (>= 1:1.2.0) | 1:1.2.5.dfsg-1
perl-modules | 5.12.4-1
liberror-perl| 0.17-1
git-man   (>> 1:1.7.5.4) | 1:1.7.5.4-1
git-man (<< 1:1.7.5.4-.) | 1:1.7.5.4-1


Recommends  (Version) | Installed
=-+-===
patch | 2.6.1-2
less  | 444-1
rsync | 3.0.8-1
ssh-client|


Suggests(Version) | Installed
=-+-===
git-doc   | 1:1.7.5.4-1
git-el|
git-arch  |
git-cvs   |
git-svn   | 1:1.7.5.4-1
git-email | 1:1.7.5.4-1
git-daemon-run|
git-gui   | 1:1.7.5.4-1
gitk  | 1:1.7.5.4-1
gitweb|







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

Bug#638657: [bugz] bugz: not working with bugzilla 3.4.10

[Török Edwin]

Package: bugz
Version: 0.7.3-2
Severity: normal

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

The bugz version in Debian is affected by this bug:
https://code.google.com/p/pybugz/issues/detail?id=27
Modifying a bug with 'bugz' reports success, but it doesn't actually modify 
anything.

If I upgrade to latest upstream (0.9.3), then I can modify bugs again via bugz.

Note that latest upstream versions appear to be here now (and needs 
python-argparse as runtime dep):
https://github.com/williamh/pybugz

Please upgrade to latest upstream.

Thanks,
--Edwin

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.3

Debian Release: wheezy/sid
  500 unstableftp.ro.debian.org
  500 unstableftp.lug.ro
  500 testing security.debian.org
  500 testing ftp.ro.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.lug.ro

--- Package information. ---
Depends  (Version) | Installed
==-+-
python | 2.6.7-2
python-central (>= 0.6.11) | 0.6.17


Package's Recommends field is empty.

Package's Suggests field is empty.






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

Bug#643656: icons not showing up - empty XDG_DATA_DIRS

[Török Edwin]

I tried moving kde to .kde-old, and logging in again but that didn't help.

I finally tracked down the problem: XDG_DATA_DIRS environment variable was 
empty which caused a number of applications to not function correctly in KDE
(pidgin not finding its icons, openbox not findings the themes, etc.).
I removed /var/cache/desktop-profiles/activated-profiles, and run 
update-profile-cache as root.

Now when I login all the icons show up in the tray as they are supposed to, 
because XDG_DATA_DIRS is no longer empty!

Best regards,
--Edwin




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

Bug#643656: icons not showing up - empty XDG_DATA_DIRS

[Török Edwin]

On 10/12/2011 04:29 PM, Kevin Krammer wrote:
> On Wednesday, 2011-10-12, Török Edwin wrote:
>> I tried moving kde to .kde-old, and logging in again but that didn't help.
>>
>> I finally tracked down the problem: XDG_DATA_DIRS environment variable was
>> empty which caused a number of applications to not function correctly in
>> KDE (pidgin not finding its icons, openbox not findings the themes, etc.).
>> I removed /var/cache/desktop-profiles/activated-profiles, and run
>> update-profile-cache as root.
>>
>> Now when I login all the icons show up in the tray as they are supposed to,
>> because XDG_DATA_DIRS is no longer empty!
> 
> Can you try unsetting XDG_DATA_DIRS and see if the problem shows up again?

This makes the problem show up again
export XDG_DATA_DIRS=
pidgin
So does this:
export XDG_DATA_DIRS=:
pidgin

This works correctly
unset XDG_DATA_DIRS
pidgin

And this is what I actually had (sorry missed the :) when I wrote my previous 
reply:
XDG_DATA_DIRS=:

> 
> XDG_DATA_DIRS unset or empty should work, applications are supposed to fall 
> back to the specified default value (/usr/share:/usr/local/share if I 
> remember 
> correctly).

Best regards,
--Edwin



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

Bug#645099: [pidgin] pidgin: should handle empty XDG_DATA_DIRS

[Török Edwin]

Package: pidgin
Version: 2.10.0-1+b1
Severity: normal

--- Please enter the report below this line. ---
Dear Maintainer,

pidgin doesn't find its icons when XDG_DATA_DIRS is empty (bug),
but it finds them when it is not set (correct behaviour).

This works:
unset XDG_DATA_DIRS
pidgin

This doesn't:
export XDG_DATA_DIRS=
pidgin

See the discussion on Debian bug #643656, and
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html.
If empty XDG_DATA_DIRS then /usr/local/share/:/usr/share/ should be
used.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.6

Debian Release: wheezy/sid
  500 unstableftp.ro.debian.org

--- Package information. ---
Depends(Version) | Installed
-+-==
pidgin-data  (>= 2.10.0) | 2.10.0-1
pidgin-data(<< 2.10.0-z) | 2.10.0-1
libatk1.0-0  (>= 1.12.4) | 2.2.0-2
libc6   (>= 2.7) | 2.13-21
libcairo2 (>= 1.2.4) | 1.10.2-6.1
libdbus-1-3   (>= 1.0.2) | 1.4.16-1
libdbus-glib-1-2   (>= 0.78) | 0.98-1
libfontconfig1(>= 2.8.0) | 2.8.0-3
libfreetype6  (>= 2.2.1) | 2.4.6-2
libgdk-pixbuf2.0-0   (>= 2.22.0) | 2.24.0-1
libglib2.0-0 (>= 2.24.0) | 2.28.6-1
libgstreamer0.10-0  (>= 0.10.10) | 0.10.35-1
libgtk2.0-0  (>= 2.24.0) | 2.24.6-2
libgtkspell0 (>= 2.0.10) | 2.0.16-1
libice6 (>= 1:1.0.0) | 2:1.0.7-2
libpango1.0-0(>= 1.18.0) | 1.29.4-1
libpurple0  (>= 2.8.0-1) | 2.10.0-1+b1
libsm6   | 2:1.2.0-2
libx11-6 | 2:1.4.4-2
libxml2  (>= 2.6.27) | 2.7.8.dfsg-5
libxss1  | 1:1.2.1-2
gconf2 (>= 2.28.1-2) | 2.32.4-1
perl-base  (>= 5.12.4-4) | 5.12.4-6
perlapi-5.12.4   |


Recommends  (Version) | Installed
=-+-===
gstreamer0.10-plugins-base| 0.10.35-1
gstreamer0.10-plugins-good| 0.10.30-1


Suggests(Version) | Installed
=-+-
gnome-panel (>= 2.1)  | 2.30.2-4+b1
 OR kdebase-workspace-bin | 4:4.6.5-3
 OR docker|
evolution-data-server (>= 1.10.0) | 3.0.3-1
libsqlite3-0   (>= 3.5.9) | 3.7.8-1







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

Bug#643656: icons not showing up - empty XDG_DATA_DIRS

[Török Edwin]

On 10/12/2011 04:39 PM, Kevin Krammer wrote:
> 
> On Wednesday, 2011-10-12, Török Edwin wrote:
>> On 10/12/2011 04:29 PM, Kevin Krammer wrote:
>>> On Wednesday, 2011-10-12, Török Edwin wrote:
>>>> I tried moving kde to .kde-old, and logging in again but that didn't
>>>> help.
>>>>
>>>> I finally tracked down the problem: XDG_DATA_DIRS environment variable
>>>> was empty which caused a number of applications to not function
>>>> correctly in KDE (pidgin not finding its icons, openbox not findings
>>>> the themes, etc.). I removed
>>>> /var/cache/desktop-profiles/activated-profiles, and run
>>>> update-profile-cache as root.
>>>>
>>>> Now when I login all the icons show up in the tray as they are supposed
>>>> to, because XDG_DATA_DIRS is no longer empty!
>>>
>>> Can you try unsetting XDG_DATA_DIRS and see if the problem shows up
>>> again?
>>
>> This makes the problem show up again
>> export XDG_DATA_DIRS=
>> pidgin
> 
> This should work.
> The spec [1] section "environment variables" says: "If $XDG_DATA_DIRS is 
> either not set or empty, a value equal to /usr/local/share/:/usr/share/ 
> should 
> be used."
> 
> This is the case "empty"
> 
> You might want to report this as a bug against pidgin.

Done.

> 
>> So does this:
>> export XDG_DATA_DIRS=:
>> pidgin
>>
>> This works correctly
>> unset XDG_DATA_DIRS
>> pidgin
> 
> The "not set" case of the spec seems to be done correctly.
> 
>> And this is what I actually had (sorry missed the :) when I wrote my
>> previous reply:
>>
>> XDG_DATA_DIRS=:
> 
> Ah. I think this is correct, if annoying, behavior in this case.

I couldn't figure out how to reproduce the XDG_DATA_DIRS=: case, unless it was 
a corrupted
/var/cache/desktop-profiles/activated_profiles file (the file is 0 sized now, 
don't know if it contained anything before).

Should there be some sanity checks in KDE / desktop-profiles scripts to check 
that XDG_DATA_DIRS make sense?
i.e. that it refers to at least one directory that exists.

Best regards,
--Edwin



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

Bug#643656: icons not showing up - empty XDG_DATA_DIRS

[Török Edwin]

On 10/12/2011 05:57 PM, Kevin Krammer wrote:
> On Wednesday, 2011-10-12, Török Edwin wrote:
>> On 10/12/2011 04:39 PM, Kevin Krammer wrote:
>>> On Wednesday, 2011-10-12, Török Edwin wrote:
> 
>>>> And this is what I actually had (sorry missed the :) when I wrote my
>>>> previous reply:
>>>
>>>> XDG_DATA_DIRS=:
>>> Ah. I think this is correct, if annoying, behavior in this case.
>>
>> I couldn't figure out how to reproduce the XDG_DATA_DIRS=: case, unless it
>> was a corrupted /var/cache/desktop-profiles/activated_profiles file (the
>> file is 0 sized now, don't know if it contained anything before).
>>
>> Should there be some sanity checks in KDE / desktop-profiles scripts to
>> check that XDG_DATA_DIRS make sense? i.e. that it refers to at least one
>> directory that exists.
> 
> You mean if it is set and not empty?

Yes.

> Hmm, I guess the real bug is with whatever created that invalid value in the 
> first place.

FWIW with the old .kde dir the tray icons are still not working (except KDE's 
own),
they are working only with a fresh .kde dir.
Even icedove which only shows a yellow rectangle and a number doesn't show 
anything with that.

I still have the old kde dir (as .kde-old), is there anything in particular I 
should look for
inthere that could cause tray icons not to work?
Or how can I debug this?

> 
> Software reading the variable should probably log if any directory in it does 
> not exist, but I don't think it has any specified remedy for getting out of 
> the 
> mess.

The script in /etc/X11/Xsession.d that sets XDG_DATA_DIRS could log that 
message to
.xsession-errors.

Best regards,
--Edwin



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

Bug#637998: [git] git prune: dumps core when run on Linux repository

[Török Edwin]

On 08/24/2011 04:58 AM, Jonathan Nieder wrote:
> fixed 637998 git/1:1.7.6-1
> quit
> 
> Hi Edwin,
> 
> Török Edwin wrote:
> 
>> When I run 'git prune' on the Linux repository I get a coredump:.
> 
> Do you still have a repository that reproduces this?
> 
> Given such a tarball, I'd be happy to bisect to find the fix and
> determine whether it is something that could be backported to squeeze.

At this point I'm not sure if this was a bug in git at all,
as I'm not able to reproduce it anymore.
memtest showed I had a 1 bit error in one of my RAM modules, maybe thats why 
git crashed.
Or maybe when I've run git prune from experimental it already pruned the objects
that caused the old git to crash (I'll make a backup of the repo next time git 
crashes as you suggested).

Feel free to close this bug as invalid, will reopen if I see it crash again.

Best regards,
--Edwin



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

Bug#643656: [plasma-desktop] KDE: applications vanishing from taskbar and icons not showing up in tray

[Török Edwin]

Package: plasma-desktop
Version: 4:4.6.5-3
Severity: normal

--- Please enter the report below this line. ---
Last week one of my hard-disks lost connectivity and RAID array went down.
digikam and the the taskbar application died with a SIGBUS. So far this was 
expected (
it probably tried to read an open file, but filesystem went away).

After I fixed the RAID array and logged into KDE, and I had no taskbar/tray 
icons anymore.
So I clicked the Panel toolbox button on top right corner, and clicked add 
panel.
Surely the taskbar and tray area was back now.

However the tray area is not working anymore, I see the clock, and the standard 
KDE icons
(clipboard, kbd layout switcher, randrtray, mixer, bluetooth, etc.), but I 
don't see
pidgin's icon at all. Of course pidgin is running. The situation persists after 
logout/login, and reboot.

How can I debug why the tray is not working? Is there some debug information I 
could provide?
What is the name of the application that provides the tray area?
(in KDE3 I think it was kicker, don't know about KDE4).

The taskbar is misbehaving too, for example icedove keeps vanishing (have to 
run icedove to
get it focused again). Don't have a definitive testcase for it, but if I switch 
to another app,
and use it for a while, and then later (half an hour?) look for icedove its 
gone.
I checked dmesg and there is no segfault message about icedove there.
Still it could've died without logging anything to dmesg, will try to confirm 
with 'ps' that its still running,
the next time it vanishes.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.0.3

Debian Release: wheezy/sid
  500 unstableftp.ro.debian.org
1 experimentalftp.lug.ro

--- Package information. ---
Depends   (Version) | Installed
===-+-===
kdebase-runtime | 4:4.6.5-1+b1
libc6(>= 2.2.5) | 2.13-21
libkcmutils4   (>= 4:4.6.3) | 4:4.6.5-2
libkdecore5(>= 4:4.6.3) | 4:4.6.5-2
libkdeui5  (>= 4:4.6.3) | 4:4.6.5-2
libkephal4abi1(= 4:4.6.5-3) | 4:4.6.5-3
libkfile4  (>= 4:4.6.3) | 4:4.6.5-2
libkidletime4  (>= 4:4.6.3) | 4:4.6.5-2
libkio5(>= 4:4.6.3) | 4:4.6.5-2
libknewstuff3-4(>= 4:4.6.3) | 4:4.6.5-2
libktexteditor4(>= 4:4.6.3) | 4:4.6.5-2
libkworkspace4(= 4:4.6.5-3) | 4:4.6.5-3
libplasma3 (>= 4:4.6.3) | 4:4.6.5-2
libplasmagenericshell4(= 4:4.6.5-3) | 4:4.6.5-3
libqt4-dbus(>= 4:4.6.1) | 4:4.7.3-8
libqt4-xml (>= 4:4.5.3) | 4:4.7.3-8
libqtcore4   (>= 4:4.7.0~beta1) | 4:4.7.3-8
libqtgui4(>= 4:4.7.0~beta2) | 4:4.7.3-8
libsolid4  (>= 4:4.6.3) | 4:4.6.5-2
libstdc++6   (>= 4.1.1) | 4.6.1-12
libtaskmanager4abi1   (= 4:4.6.5-3) | 4:4.6.5-3
libx11-6| 2:1.4.4-2
libxext6| 2:1.3.0-3
plasma-widgets-workspace  (= 4:4.6.5-3) | 4:4.6.5-3


Recommends (Version) | Installed
-+-===
kdebase-workspace| 4:4.6.5-3


Package's Suggests field is empty.






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

Bug#643656: Acknowledgement ([plasma-desktop] KDE: applications vanishing from taskbar and icons not showing up in tray)

[Török Edwin]

OK, here's a way to make it vanish:
1. click icedove taskbar icon once to focus it
2. click it again
3. click it a 3rd time
4. Notice that icon vanished.
5. Confirm that it is still running (ps -ef|grep icedove)
edwin 5534  4139  3 10:21 ?00:08:42 /usr/lib/icedove/icedove-bin 
--sm-config-prefix /icedove-bin-YjY0oX/ --sm-client-id 
10c5d3626900013034577920045160010 --screen 0
6. Notice that it vanished from the Alt-Tab list too
7. Run icedove again, then it'll focus the window and make the taskbar icon 
appear again, and appear in the alt-tab list too
8. Confirm that its still the same icedove with 'ps', check that its same PID:
edwin 5534  4139  3 10:21 ?00:08:52 /usr/lib/icedove/icedove-bin 
--sm-config-prefix /icedove-bin-YjY0oX/ --sm-client-id 
10c5d3626900013034577920045160010 --screen 0

Hopefully this is enough information to help you reproduce this bug.

Best regards,
--Edwin



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

Bug#714743: [bash] wait: specify that you can only wait for child PIDs

[Török Edwin]

Package: bash
Version: 4.2+dfsg-1
Severity: normal

--- Please enter the report below this line. ---
$ wait 1
bash: wait: pid 1 is not a child of this shell

The manpage of bash, dash and wait should mention that the PID has to be a 
child of the shell.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.10.0

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.ro.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-
base-files  (>= 2.1.12) | 7.2
debianutils   (>= 2.15) | 4.3.4


Recommends(Version) | Installed
===-+-
bash-completion (>= 20060301-0) | 1:2.0-1


Suggests  (Version) | Installed
===-+-===
bash-doc| 


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

Bug#711599: [check] -lrt missing too

[Török Edwin]

Package: check
Version: 0.9.10-1

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

-lrt is missing from `pkg-config check --libs` too (it is present with static):

/usr/lib/x86_64-linux-gnu/libcheck_pic.a(check_run.o): In function 
`srunner_run':
(.text+0x8f0): undefined reference to `timer_create'

Please restore the .so or fix the .pc

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.9.5

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org
  500 stable  security.debian.org
  500 stable  ftp.ro.debian.org
1 experimentalftp.ro.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-=
dpkg (>= 1.15.4)  | 1.16.10
 OR install-info  | 5.1.dfsg.1-3


Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#712387: [libqt4-script] Javascript JIT: excessive executable VIRT usage (>2GB)!

[Török Edwin]

Package: libqt4-script
Version: 4:4.8.4+dfsg-4
Severity: normal

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

I've noticed that plasma-desktop (and kwin too) is using a LOT of VIRT, i.e. 
>2GB:
 5254 edwin 20   0 2943320  65652  35756 t   0.0  0.8   0:02.00 
plasma-desktop 

On a machine with 8GB of physical RAM and swap turned off this quickly gets you 
to the limit of OOM killing other apps (kwin + plasma-desktop + consolekit all 
using 1>GB, and then icedove+iceweasel too).

After some debugging I've traced the culprit to libqt4-script called from the 
'Device Notifier' widget:
#1  0x0033b1ca2dbc in FixedVMPoolAllocator (totalHeapSize=2147483648, 
commonSize=, this=0x1763a70)
at 
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:308
308 m_base = mmap(reinterpret_cast(randomLocation), 
m_totalHeapSize, INITIAL_PROTECTION_FLAGS, MAP_PRIVATE | MAP_ANON | 
MAP_NORESERVE, VM_TAG_FOR_EXECUTABLEALLOCATOR_MEMORY, 0);

(gdb) print m_totalHeapSize 
$6 = 2147483648

So apparently some Javascript JIT maps 2GB of executable memory, due to:
#if CPU(X86_64)
// These limits suitable on 64-bit platforms (particularly x86-64, where we 
require all jumps to have a 2Gb max range).
#define VM_POOL_SIZE (2u * 1024u * 1024u * 1024u) // 2Gb

See here for some discussions upstream, but leading to no solution (still 
allocates 2GB):
https://bugs.webkit.org/show_bug.cgi?id=42756

It seems silly to allocate 2GB just to avoid having jumps crossing 2GB 
boundaries, when there is a dedicated mmap() flag that ensures all addresses 
are within 1st 2GB: MAP_32BIT.

I'd suggest to use that flag and set the VM_POOL_SIZE to 32MB like it is for 
32-bit apps.

It would be best if the JIT could also be disabled at runtime for 
libqt4-script, for applications that don't strictly require it, like plasma, 
etc.

Full backtrace:

#0  0x003134ce43ca in mmap64 () at ../sysdeps/unix/syscall-template.S:81
#1  0x0033b1ca2dbc in FixedVMPoolAllocator (totalHeapSize=2147483648, 
commonSize=, this=0x1763a70)
at 
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:308
#2  QTJSC::ExecutablePool::systemAlloc (size=size@entry=16384)
at 
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:443
#3  0x0033b1d27a99 in ExecutablePool (n=, 
this=0x7fffe40de960)
at ../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:258
#4  create (n=) at 
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:97
#5  ExecutableAllocator (this=0x7fffe40d89c8) at 
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:150
#6  QTJSC::JSGlobalData::JSGlobalData (this=0x7fffe40d7800, isShared=)
at ../3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp:146
#7  0x0033b1d2825c in QTJSC::JSGlobalData::create ()
at ../3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp:205
#8  0x0033b1dc87e0 in QScriptEnginePrivate::QScriptEnginePrivate 
(this=0x159fa70) at api/qscriptengine.cpp:979
#9  0x0033b1dc97d6 in QScriptEngine::QScriptEngine (this=0x159f538) at 
api/qscriptengine.cpp:1964
#10 0x0033b37b362c in QDeclarativeScriptEngine::QDeclarativeScriptEngine 
(this=0x159f538, priv=0x159f430)
at qml/qdeclarativeengine.cpp:385
#11 0x0033b37bc54f in QDeclarativeEnginePrivate::QDeclarativeEnginePrivate 
(this=0x159f430, e=0x10295c0)
at qml/qdeclarativeengine.cpp:356
#12 0x0033b37bc831 in QDeclarativeEngine::QDeclarativeEngine 
(this=0x10295c0, parent=0x18c5e30)
at qml/qdeclarativeengine.cpp:642
#13 0x779d49c4 in Plasma::DeclarativeWidget::DeclarativeWidget 
(this=0x18c5e30, parent=)
at ../../plasma/widgets/declarativewidget.cpp:196
#14 0x7fffdedca08f in ?? () from 
/usr/lib/kde4/plasma_appletscript_declarative.so
#15 0x7790310f in Plasma::Applet::init (this=0x9d4ad0) at 
../../plasma/applet.cpp:249
#16 0x7fffed65dd57 in SystemTray::PlasmoidTask::createWidget 
(this=0x13660a0, host=0xa84300)
at 
/tmp/kde-workspace-4.8.4/plasma/generic/applets/systemtray/protocols/plasmoid/plasmoidtask.cpp:105
#17 0x7fffed64facc in SystemTray::Task::widget (this=0x13660a0, 
host=0xa84300, createIfNecessary=true)
at 
/tmp/kde-workspace-4.8.4/plasma/generic/applets/systemtray/core/task.cpp:79
#18 0x7fffed67415b in SystemTray::TaskArea::addWidgetForTask 
(this=0xcd4b20, task=0x13660a0)
at 
/tmp/kde-workspace-4.8.4/plasma/generic/applets/systemtray/ui/taskarea.cpp:265
#19 0x7fffed673b33 in SystemTray::TaskArea::addTask (this=0xcd4b20, 
task=0x13660a0)
at 
/tmp/kde-workspace-4.8.4/plasma/generic/applets/systemtray/ui/taskarea.cpp:196
#20 0x7fffed675f96 in SystemTray::TaskArea::qt_static_metacall 
(_o=0xcd4b20, _c=QMetaObject::InvokeMetaMethod, _id=2, 
_a=0x7fffc660) at 
/tmp/kde-workspace-4.8.4/plasma/generic/applets/systemtray/taskarea.moc:66
#21 0x0033b478cdcf in QMetaObject::activate (sender=0x97ad0

Bug#712390: [qt4-x11] qt4-x11: FTBFS in unstable

[Török Edwin]

Package: qt4-x11
Version: 4:4.8.4+dfsg-4
Severity: normal

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

Tried to rebuild the Qt4 package in unstable to test a patch for #712387, but 
it didn't build:

# apt-get build-dep qt4-x11
[...]
$ apt-get source qt4-x11
[...]
$ cd qt4-x11-4.8.4+dfsg
$ g++ --version
g++ (Debian 4.7.3-4) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ debian/rules binary
[...]
g++ -c -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -I/usr/include/freetype2 -pthread 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -O2 
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC 
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII 
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER 
-DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG 
-DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 
-DQT_HAVE_SSE3 -DQT_HAVE_SSSE3 -DQT_HAVE_SSE4_1 -DQT_HAVE_SSE4_2 -DQT_HAVE_AVX 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/glibc-g++ -I. 
-I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal 
-I../../tools/shared -I../3rdparty/harfbuzz/src -I../3rdparty/md5 
-I../3rdparty/md4 -I.moc/release-shared -o 
.obj/release-shared/qabstractanimation.o animation/qabst
 ractanim
 a
tion.cpp
In file included from ../../include/QtCore/qatomic_armv5.h:1:0,
 from 
../../include/QtCore/../../src/corelib/arch/qatomic_arm.h:70,
 from ../../include/QtCore/qatomic_arm.h:1,
 from 
../../include/QtCore/../../src/corelib/arch/qatomic_arch.h:56,
 from ../../include/QtCore/qatomic_arch.h:1,
 from 
../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:227,
 from ../../include/QtCore/qbasicatomic.h:1,
 from 
../../include/QtCore/../../src/corelib/thread/qatomic.h:46,
 from ../../include/QtCore/qatomic.h:1,
 from 
../../include/QtCore/../../src/corelib/tools/qbytearray.h:45,
 from ../../include/QtCore/qbytearray.h:1,
 from ../../include/QtCore/../../src/corelib/tools/qstring.h:46,
 from ../../include/QtCore/qstring.h:1,
 from 
../../include/QtCore/../../src/corelib/kernel/qobject.h:48,
 from ../../include/QtCore/qobject.h:1,
 from animation/qabstractanimation.h:45,
 from animation/qabstractanimation.cpp:145:
../../include/QtCore/../../src/corelib/arch/qatomic_armv5.h: In member function 
‘int QBasicAtomicInt::fetchAndStoreOrdered(int)’:
../../include/QtCore/../../src/corelib/arch/qatomic_armv5.h:236:26: error: 
‘count’ was not declared in this scope
../../include/QtCore/../../src/corelib/arch/qatomic_armv5.h:236:26: note: 
suggested alternative:
In file included from /usr/include/c++/4.7/algorithm:63:0,
 from 
../../include/QtCore/../../src/corelib/global/qglobal.h:68,
 from ../../include/QtCore/qglobal.h:1,
 from 
../../include/QtCore/../../src/corelib/global/qnamespace.h:45,
 from ../../include/QtCore/qnamespace.h:1,
 from 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs.h:45,
 from ../../include/QtCore/qobjectdefs.h:1,
 from 
../../include/QtCore/../../src/corelib/kernel/qobject.h:47,
 from ../../include/QtCore/qobject.h:1,
 from animation/qabstractanimation.h:45,
 from animation/qabstractanimation.cpp:145:
/usr/include/c++/4.7/bits/stl_algo.h:4647:5: note:   ‘std::count’
In file included from ../../include/QtCore/qatomic_armv5.h:1:0,
 from 
../../include/QtCore/../../src/corelib/arch/qatomic_arm.h:70,
 from ../../include/QtCore/qatomic_arm.h:1,
 from 
../../include/QtCore/../../src/corelib/arch/qatomic_arch.h:56,
 from ../../include/QtCore/qatomic_arch.h:1,
 from 
../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:227,
 from ../../include/QtCore/qbasicatomic.h:1,
 from 
../../include/QtCore/../../src/corelib/thread/qatomic.h:46,
 from ../../include/QtCore/qatomic.h:1,
 from 
../../include/QtCore/../../src/corelib/tools/qbytearray.h:45,
 from ../../include/QtCore/qbytearray.h:1,
 from ../../include/QtCore/../../src/corelib/tools/qstring.h:46,
 from ../../include/QtCore/qstring.h:1,
 from 
../../include/QtCore/../../src/corelib/kernel/qobject.h:48,
 from ../../include/QtCore/qobject.h:1,
  

Bug#712387: patch updated

[Török Edwin]

forwarded 712387 https://bugreports.qt-project.org/browse/QTBUG-32459
forwarded 712387 https://bugs.webkit.org/show_bug.cgi?id=118733
thanks

This is still an issue for libqt4-script version 4:4.8.5+dfsg-2.
I have updated the patch and submitted it upstream both to WebKit and Qt. Sorry 
for taking so long to forward patch upstream.

After installing the patched libqt4-script the memory usage of plasma-desktop 
is:
 3867 edwin 20   0 1098436 134248  43864 S   5.3  1.6   1:54.25 
plasma-desktop

There are actually two copies of the code in the Qt sources:
src/3rdparty/javascriptcore
src/3rdparty/webkit/Source/JavascriptCore/

The one I had problems with, and the one I patched is the former (in 
libqt4-script), but you are probably right that the latter (libqtwebkit4) may 
also have the same problem.

Thought to file a bug about the embedded source code, but there is one already: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684251

Thanks,
--Edwin
diff -ru a/src/3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp b/src/3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp
--- a/src/3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp	2013-06-07 08:16:58.0 +0300
+++ b/src/3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp	2013-07-16 10:24:09.589121125 +0300
@@ -39,11 +39,9 @@
 
 #if CPU(X86_64)
 // These limits suitable on 64-bit platforms (particularly x86-64, where we require all jumps to have a 2Gb max range).
-#ifdef QT_USE_ONEGB_VMALLOCATOR
-#define VM_POOL_SIZE (1024u * 1024u * 1024u) // 1Gb
-#else
-#define VM_POOL_SIZE (2u * 1024u * 1024u * 1024u) // 2Gb
-#endif
+// On x86-64, where we require all jumps to have a 2Gb max range we'll use
+// MAP_32BIT
+#define VM_POOL_SIZE (32u * 1024u * 1024u) // 32Mb
 #define COALESCE_LIMIT (16u * 1024u * 1024u) // 16Mb
 #else
 // These limits are hopefully sensible on embedded platforms.
@@ -309,7 +307,7 @@
 randomLocation += (1 << 24);
 randomLocation <<= 21;
 #endif
-m_base = mmap(reinterpret_cast(randomLocation), m_totalHeapSize, INITIAL_PROTECTION_FLAGS, MAP_PRIVATE | MAP_ANON | MAP_NORESERVE, VM_TAG_FOR_EXECUTABLEALLOCATOR_MEMORY, 0);
+m_base = mmap(reinterpret_cast(randomLocation), m_totalHeapSize, INITIAL_PROTECTION_FLAGS, MAP_PRIVATE | MAP_ANON | MAP_NORESERVE | MAP_32BIT, VM_TAG_FOR_EXECUTABLEALLOCATOR_MEMORY, 0);
 if (m_base == MAP_FAILED)
 CRASH();
 
Only in b/src/3rdparty/javascriptcore/JavaScriptCore/jit: ExecutableAllocatorFixedVMPool.cpp.orig
Only in b/src/3rdparty/javascriptcore/JavaScriptCore/jit: ExecutableAllocatorFixedVMPool.cpp.rej

Bug#647470: [libqt4-script] upstream

[Török Edwin]

forwarded 647470 https://bugreports.qt-project.org/browse/QTBUG-32460
thanks

There are actually 2 embedded copies of JavascriptCore in Qt, and one of them 
allows disabling
the JIT via an env var. Unfortunately not the one used by KWin and 
libqt4-script.

I've filed a bug upstream about this:
https://bugreports.qt-project.org/browse/QTBUG-32460

It should be a matter of backporting the env var from one javascriptcore to the 
other (or better yet
get rid of the double-embedded code).

--Edwin


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

Bug#726107: [texlive-base] /etc/papersize changes not working due to bad path in /etc/libpaper.d/texlive-base

[Török Edwin]

Package: texlive-base
Version: 2013.20131010-1
Severity: normal

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

Nothing happens if I change papersize:

$ cat /etc/papersize
letter
$ sudo paperconfig -p a4
$ sudo paperconfig -p letter
$ 

The reason seems to be that /etc/libpaper.d/texlive-base refers to a path that 
doesn't exist:
test -x /usr/share/texlive/texmf/texconfig/tcfmgr || exit 0

If I modify that line to this then it works:
test -x /usr/share/texlive/texmf-dist/texconfig/tcfmgr || exit 0

$ sudo paperconfig -p a4
sudo paperconfig -p a4
/usr/bin/tl-paper: setting paper size for dvipdfmx to a4.
/usr/bin/tl-paper: setting paper size for dvips to a4.
/usr/bin/tl-paper: setting paper size for pdftex to a4.
/usr/bin/tl-paper: setting paper size for xdvi to a4.
Running mktexlsr. This may take some time... done.
Building format(s) --refresh.
This may take some time... done.

$ sudo paperconfig -p letter
/usr/bin/tl-paper: setting paper size for dvipdfmx to a4.
/usr/bin/tl-paper: setting paper size for dvips to a4.
/usr/bin/tl-paper: setting paper size for pdftex to a4.
/usr/bin/tl-paper: setting paper size for xdvi to a4.
Running mktexlsr. This may take some time... done.
Building format(s) --refresh.
This may take some time... done.



--- System information. ---
Architecture: amd64
Kernel:   Linux 3.11.4

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
tex-common(>= 4.03) | 4.04
debconf   (>= 0.5)  | 1.5.51
 OR debconf-2.0 | 
dpkg   (>= 1.14.18) | 1.17.1
texlive-binaries (>= 2013.20130512) | 2013.20130729.30972-2
xdg-utils   | 1.1.0~rc1+git20111210-7
luatex  (>= 0.70.1) | 0.76.0-3
ucf | 3.0027+nmu1
libpaper-utils  | 1.1.24+nmu2
debconf   (>= 0.5)  | 1.5.51
 OR debconf-2.0 | 
ucf | 3.0027+nmu1
debconf(>= 1.4.69)  | 1.5.51
 OR cdebconf  (>= 0.39) | 
dpkg   (>= 1.14.18) | 1.17.1


Package Status(Version) | Installed
===-+-===
tex-common  | 4.04
texlive-binaries| 2013.20130729.30972-2


Recommends   (Version) | Installed
==-+-
lmodern(>= 0.93.3) | 2.004.4-3


Suggests   (Version) | Installed
-+-===
perl-tk  | 
ghostscript  | 9.05~dfsg-8
gv   | 
 OR postscript-viewer| 
xpdf-reader  | 
 OR pdf-viewer   | 
debhelper (>= 7.0.8) | 9.20130921



--- Output from package bug script ---


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

Bug#544223: [argyll] dispwin crashes

[Török Edwin]

Package: argyll
Version: 1.5.1-3

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

I run dispcalGUI-apply-profiles and I noticed this in dmesg:
[ 2248.894077] dispwin[2172]: segfault at 10 ip 0030bc801626 sp 
7fffed74b100 error 4 in libyajl.so.2.0.4[30bc80+9000]

This might be related to the Debian patch from 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544223
The embedded yajl_alloc has this API:
yajl_handle YAJL_API yajl_alloc(const yajl_callbacks * callbacks,
const yajl_parser_config * config,
const yajl_alloc_funcs * allocFuncs,
void * ctx);

The external one has this API:
YAJL_API yajl_handle yajl_alloc(const yajl_callbacks * callbacks,
yajl_alloc_funcs * afs,
void * ctx);

Also it looks like the part of the patch from #544223 that changed the #include 
to use the external yajl headers was not applied, so at build time it uses the 
embedded yajl headers, and at link time the external yajl lib ...

See below for the backtrace, as you can see hand is NULL (0x0):

Core was generated by `/usr/bin/dispwin -d1 -c -L'.
Program terminated with signal 11, Segmentation fault.
#0  yajl_parse (hand=hand@entry=0x0, 
jsonText=jsonText@entry=0x7fffed74b1c0 "{\n  \"devices\": {\n
\"display\": {\n  \"1\": {\n\"EDID\": \"0x00", 'F' , 
"004C2DE5033232575402120103802F1E782AEE91A3544C99260F5054BFEF80B30081808140714F01010101010101017C2E90A0601A1E4030203600DA"...,
 jsonTextLen=465) at /tmp/buildd/yajl-2.0.4/src/yajl.c:124
#1  0x0030be202fb5 in jcnf_read (p=p@entry=0x1f3f580) at jcnf.c:801
#2  0x0030be203216 in new_jcnf (pev=pev@entry=0x7fffed74ba9c, 
fname=fname@entry=0x1f3fa80 "/home/edwin/.config/color.jcnf", 
modify=modify@entry=jc_read, create=create@entry=jc_no_create) at 
jcnf.c:1205
#3  0x0030bde020d0 in ucmm_get_monitor_profile (edid=0x1f3e400 "", 
edid_len=128, display_name=0x1f3ea50 ":0.0", 
profile=profile@entry=0x7fffed74bbd8) at ucmm.c:826
#4  0x00407170 in dispwin_get_profile (p=0x1f3e820, name=0x7fffed74dd20 
"", mxlen=1024) at dispwin.c:3042
#5  0x00403d1f in main (argc=, argv=) at 
dispwin.c:5358



--- System information. ---
Architecture: amd64
Kernel:   Linux 3.10.6

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-==
libc6(>= 2.15) | 
libicc2| 
libimdi0   | 
libjpeg8   (>= 8c) | 
libtiff4 (>> 3.9.5-3~) | 
libusb-0.1-4 (>= 2:0.1.12) | 
libx11-6   | 
libxext6   | 
libxinerama1   | 
libxrandr2(>= 2:1.2.0) | 
libxss1| 
libxxf86vm1| 
libyajl2(>= 2.0.4) | 


Recommends  (Version) | Installed
=-+-===
consolekit| 0.4.5-3.1
udev(>= 146~) | 175-7.2


Package's Suggests field is empty.


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

Bug#714168: [xul-ext-adblock-plus] adblock plus: typo correction potential security issue

[Török Edwin]

Package: xul-ext-adblock-plus
Version: 2.2.4-1
Severity: normal

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

Although this is disabled by default AdBlock will ask you if you want to enable 
it when you typo a website for the first time. There is no indication that 
enabling this feature would download a set of rules
from a remote website over HTTP!

In lib/typoRules.js typo correction rules are downloaded from a remote site 
over http:
 loadRulesFrom("http://urlfixer.org/download/rules.json?version="; + 
RULES_VERSION, false, function(success)

This ruleset can contain arbitrary regular expressions that can rewrite URLs, 
insert affiliate tags, etc.,
so controlling this ruleset would allow an attacker to control what websites 
you are visiting.

Fixing this is unfortunately not as simple as using an https:// URL, as 
although the website supports https the download URL no longer works for the 
rules.json over HTTPS.

I'm not sure what the appropriate course of action would be, but here are some 
suggestions:
 * warn the user that enabling typo correction makes them vulnerable
 * warn them that enabling typo correction might insert some affiliate tags 
(see Monetization here:
https://adblockplus.org/blog/typo-correction-feature-in-adblock-plus)
 * have upstream provide an HTTPs URL for the rules
 * have a Debian package that provides the rules.json


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.9.5

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.ro.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-===
iceweasel (>= 16.0)  | 17.0.7esr-1
 OR icedove   (>= 16.0)  | 17.0.5-2
 OR iceape (>= 2.13) | 


Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#714168: Adblock Edge

[Török Edwin]

FWIW Adblock Edge doesn't have typoFixer.js, so doesn't have this issue.


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

Bug#714352: [coreutils] seq -s not working

[Török Edwin]

Package: coreutils
Version: 8.20-3
Severity: normal

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

On Debian sid (incorrect):
$ /usr/bin/seq -s 'a' 3
1
2a3a

On Debian wheezy (correct):
$ /usr/bin/seq -s 'a' 3
1a2a3

The manpage says for -s: "use STRING to separate numbers (default: \n)".
And the info page says: "Separate numbers with STRING; default is a newline.  
The output always terminates with a newline."

Apparently the unstable version of seq confuses the first separator and the 
final newline, i.e. it SHOULD replace the first separator with 'a', and it 
SHOULDN'T replace the terminating newline with an 'a'.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.9.7

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.ro.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-=
dpkg (>= 1.15.4)  | 1.16.10
 OR install-info  | 5.1.dfsg.1-3


Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#648551: [libvirt-bin] libvirt-bin: can't find radvd (missing Build-Depends?)

[Török Edwin]

Package: libvirt-bin
Version: 0.9.6-2
Severity: normal

--- Please enter the report below this line. ---
libvirt supports IPv6 in the xml configuration file:
https://bugzilla.redhat.com/show_bug.cgi?id=567124#c7

However when I try that in Debian I get an error:
virsh # net-start default
error: Failed to start network default
error: Cannot find radvd - Possibly the package isn't installed: No such file 
or directory

This is probably because libvirt package doesn't Build-Depend on radvd, but
radvd is checked for at configure time:
AC_PATH_PROG([RADVD], [radvd], [radvd],
[/sbin:/usr/sbin:/usr/local/sbin:$PATH])

Could you add a Build-Depend on radvd to fix this?

Thanks,
--Edwin

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.1.1

Debian Release: wheezy/sid
  500 unstableiota.nren.ro
  500 unstableftp.lug.ro

--- Package information. ---
Depends  (Version) | Installed
==-+-
libavahi-client3   (>= 0.6.16) | 0.6.30-5
libavahi-common3   (>= 0.6.16) | 0.6.30-5
libblkid1  (>= 2.17.2) | 2.19.1-5
libc6(>= 2.11) | 2.13-21
libcap-ng0 | 0.6.6-1
libdevmapper1.02.1  (>= 2:1.02.20) | 2:1.02.67-1
libgcrypt11 (>= 1.4.5) | 1.5.0-3
libgnutls26(>= 2.12.6.1-0) | 2.12.14-2
libnl1(>= 1.1) | 1.1-7
libparted0debian1   (>= 2.2-1) | 2.3-8
libpcap0.8  (>= 0.9.8) | 1.1.1-10
libpciaccess0  | 0.12.1-2
libreadline6  (>= 6.0) | 6.2-7
libsasl2-2 | 2.1.25.dfsg1-2
libudev0(>= 0.140) | 172-1
libvirt0   (= 0.9.6-2) | 0.9.6-2
libxenstore3.0  (>= 3.2.0) | 4.1.1-3
libxml2 (>= 2.7.4) | 2.7.8.dfsg-5
libyajl1(>= 1.0.5) | 1.0.12-2
adduser| 3.113
logrotate  | 3.7.8-6
gettext-base   | 0.18.1.1-5


Recommends   (Version) | Installed
==-+-
netcat-openbsd | 1.89-4
bridge-utils   | 1.5-2
dnsmasq-base   (>= 2.46-1) | 2.59-2
iptables   (>= 1.4.10) | 1.4.12-1
qemu-kvm   | 0.15.1+dfsg-1
 OR qemu(>= 0.9.1) | 0.15.1+dfsg-1
libxml2-utils  | 2.7.8.dfsg-5
gawk   | 1:3.1.8+dfsg-0.1
ebtables   | 2.0.9.2-2
dmidecode  | 2.11-4
iproute| 20110629-1
parted | 2.3-8


Suggests (Version) | Installed
==-+-===
policykit-1| 0.102-1
radvd  | 1:1.8-1.2







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

Bug#657010: [login] 'su' should be PIE

[Török Edwin]

Package: login
Version: 1:4.1.4.2+svn3283-3
Severity: normal

--- Please enter the report below this line. ---
See CVE-2012-0056, a non-PIE 'su' binary makes it very easy to exploit.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.2.0

Debian Release: wheezy/sid
  500 unstableiota.nren.ro
  500 unstableftp.lug.ro

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.






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

Bug#657010: [Pkg-shadow-devel] Bug#657010: [login] 'su' should be PIE

[Török Edwin]

On 01/23/2012 08:53 PM, Nicolas François wrote:
> Hello,
> 
> On Mon, Jan 23, 2012 at 03:06:46PM +0200, edwinto...@gmail.com wrote:
>>
>> See CVE-2012-0056, a non-PIE 'su' binary makes it very easy to exploit.
> 
> Would you mind giving a bit more information?
> 
> I unfortunately stick to this PIE definition from wikipedia:

PIE refers to -fPIE from GCC of course.
Using that flag doesn't completely prevent the exploit though.

>   baked dish which is usually made of a pastry dough casing that
>   covers or completely contains a filling of various sweet or
>   savoury ingredients.
> which does not help understanding how to PIE 'su'.
> 
> Also, I have no access to CVE-2012-0056, which is under review as of
> today.

Here is a good summary and discussions:
https://lwn.net/Articles/476684/

> References I could find indicate an issue in the Linux kernel handling of
> /proc//mem
> 
> As of using hardening compiler / linker options, I have no idea if this is
> a common practice / recommended / used in other packages.
> Would it make sense to enable such flags if not done in the PAM modules or
> by other suid programs?
> 

Apparently packages should adopt hardening flags for wheezy:
http://wiki.debian.org/Hardening#State_of_implementation

Best regards,
--Edwin



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

Bug#657010: [login] 'su' should be PIE

[Török Edwin]

On 01/24/2012 09:13 PM, Nicolas François wrote:
> Hi,
> 
> On Tue, Jan 24, 2012 at 02:28:06PM +0200, xr...@yandex.ru wrote:
>>
>> Currently I'm reading the
>> http://wiki.debian.org/Hardening#Using_Hardening_Options
>> part, but it's still unclear for me how to apply
>> this stuff to shadow builds (assuming that the
>> last time I built shadow was more than 4 years ago
>> IIRC).
> 
> After a few failures, I think I get a working patch for debian/rules.
> I still need to check whether the test suite pass successfully.
> 
> Are there some known issues with the hardening flags that should be
> checked specifically?
> (except for performances, which should not be a problem for shadow utils).

With a recent GCC (and GDB) everything should be fine, hopefully it'll fail at 
build time if anything
is very wrong (like a failing -Wformat check).

But you might want to check if you can still debug it properly with GDB,
at least if stack traces still work or not.
(trigger a crash on purpose for example and see if the crash has a proper 
backtrace).

Best regards,
--Edwin



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

Bug#671997: [texlive-latex-recommended] koma-script/scrguien.pdf: some broken references

[Török Edwin]

On 2012-05-24 23:52, Hilmar Preusse wrote:
> On 24.05.12 Török Edwin (edwin+ml-deb...@etorok.net) wrote:
>> On 2012-05-09 01:32, Norbert Preining wrote:
>>> On Di, 08 Mai 2012, Török Edwin wrote:
> 
> Hi,
> 
>>>> "The latter is explained in the expert section of this document in ?? from 
>>>> ?? onwards."
>>>>
>>>> FWIW its the same on CTAN, so its likely a problem with the original 
>>>> document:
>>>> ftp://www.ctan.org/ctan/macros/latex/contrib/koma-script/scrguien.pdf
>>>
>>> Thanks, if you find time, please report it to the up-upstream author
>>> Markus Kohm so that he can fix it in an upcoming release.
>>>
>>
>> Just checked again, and this appears to be fixed already in Koma
>> script 3.11 (20120515).
>>
> So, can we close that bug as solved?

AFAICT Debian has Koma-Script v3.10a, so technically it'll only be fixed when 
that package is upgraded,
but yes you can close the bug, there is nothing to do here on the Debian-side, 
sorry if I wasted time.

--Edwin




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

Bug#671997: [texlive-latex-recommended] koma-script/scrguien.pdf: some broken references

[Török Edwin]

Package: texlive-latex-recommended
Version: 2011.20120424-1
Severity: minor

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

I've noticed a broken reference while reading 
/usr/share/texlive/texmf-dist/doc/latex/koma-script/scrguien.pdf
Page 16 says:
"The latter is explained in the expert section of this document in ?? from ?? 
onwards."

FWIW its the same on CTAN, so its likely a problem with the original document:
ftp://www.ctan.org/ctan/macros/latex/contrib/koma-script/scrguien.pdf


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.4.0-rc5

Debian Release: wheezy/sid
  500 unstableiota.nren.ro
  500 unstableftp.lug.ro
  500 testing iota.nren.ro

--- Package information. ---
Depends   (Version) | Installed
===-+-=
texlive-binaries(>= 2011-0) | 2011.20120507-1
texlive-latex-base   (>= 2011.20120424) | 2011.20120424-1
texlive-common (>= 2011.20120424-1) | 2011.20120424-1
dpkg   (>= 1.14.18) | 1.16.3
tex-common   (>= 3) | 3.10
debconf   (>= 0.5)  | 1.5.43
 OR debconf-2.0 |
ucf | 3.0025+nmu3
debconf(>= 1.4.69)  | 1.5.43
 OR cdebconf  (>= 0.39) |
dpkg   (>= 1.14.18) | 1.16.3


Package Status(Version) | Installed
===-+-===
tex-common  | 3.10
texlive-binaries| 2011.20120507-1


Recommends   (Version) | Installed
==-+-=
latex-xcolor   (>= 2.09-1) | 2.11-1
texlive-latex-recommended-doc  | 2011.20120424-1
prosper   (>= 1.00.4+cvs.2006.10.22-1) | 
1.00.4+cvs.2007.05.01-4
latex-beamer  (>= 3.06.dfsg.1-0.1) | 3.10-1


Suggests   (Version) | Installed
-+-===
debhelper (>= 7.0.8) | 9.20120419



--- Output from package bug script ---




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

Bug#658252: Info received ([libcairo2] firefox/pidgin very bad text rendering)

[Török Edwin]

Seems to be fixed by xserver-xorg-video-radeon 6.14.4-2 which contains the 
fixes from https://bugs.freedesktop.org/show_bug.cgi?id=47266

Would probably be a good idea to add a requirement to libcairo 1.12.0-2:
Breaks: xserver-xorg-video-radeon (< 6.14.4-2), xserver-xorg-video-ati (< 
6.14.4-2)

Best regards,
--Edwin



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

Bug#539519: Crashes when opening samples from blender gamekit1

[Török Edwin]

On 2012-05-18 16:28, Matteo F. Vescovi wrote:
> Hi Edwin!
> 
> Could you possibly test if actual blender version in unstable suite has
> this same issue you reported 3 years ago?

Still crashing, stacktrace a bit different:
$ gdb --args blender SuperG.blend
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/blender...Reading symbols from 
/usr/lib/debug/usr/bin/blender...(no debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/blender SuperG.blend
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x73341700 (LWP 5830)]
[New Thread 0x72b40700 (LWP 5831)]
[New Thread 0x7233f700 (LWP 5832)]
[New Thread 0x71b3e700 (LWP 5833)]
[New Thread 0x7133d700 (LWP 5834)]
[New Thread 0x70b3c700 (LWP 5835)]
[New Thread 0x70335700 (LWP 5836)]
[Thread 0x70335700 (LWP 5836) exited]
AL lib: alcOpenDevice: Option 'format' is deprecated, please use 'channels' and 
'sample-type'
[New Thread 0x70335700 (LWP 5837)]
[New Thread 0x7fffefb34700 (LWP 5838)]
[New Thread 0x7fffef333700 (LWP 5839)]
[Thread 0x7fffef333700 (LWP 5839) exited]
[New Thread 0x7fffed9c1700 (LWP 5840)]
read blend: /tmp/gamekit1-cdrom/Demos/SuperG.blend
Detected GL_ARB_texture_env_combine
Detected GL_ARB_texture_cube_map
Detected GL_ARB_multitexture
Detected GL_ARB_shader_objects
Detected GL_ARB_vertex_shader
Detected GL_ARB_fragment_shader
Detected GL_ARB_vertex_program
Detected GL_ARB_depth_texture
Detected GL_EXT_separate_specular_color
Python error compiling script - object 'Mast.005', controller 'cont1':
  File "StartGame", line 2
print "SuperG version 1.0"
 ^
SyntaxError: invalid syntax
Warning, sensor "sensor1" has lost a link to a controller (link 2 of 2) from 
object "Schranke"
possible causes are partially appended objects or an error reading the 
file,logic may be incorrect

Blender Game Engine Started
Python script error - object 'Player', controller 'Velocity':
Traceback (most recent call last):
  File "Velocity", line 8, in 
AttributeError: 'SCA_PythonController' object has no attribute 'getOwner'
[New Thread 0x7fffef333700 (LWP 5841)]

Program received signal SIGSEGV, Segmentation fault.
0x00eb70b9 in KX_ConvertBulletObject(KX_GameObject*, RAS_MeshObject*, 
DerivedMesh*, KX_Scene*, PHY_ShapeProps*, PHY_MaterialProps*, 
KX_ObjectProperties*) ()
(gdb) bt
#0  0x00eb70b9 in KX_ConvertBulletObject(KX_GameObject*, 
RAS_MeshObject*, DerivedMesh*, KX_Scene*, PHY_ShapeProps*, PHY_MaterialProps*, 
KX_ObjectProperties*) ()
#1  0x00e4b005 in BL_CreatePhysicsObjectNew(KX_GameObject*, Object*, 
RAS_MeshObject*, KX_Scene*, int, e_PhysicsEngine, KX_BlenderSceneConverter*, 
bool) ()
#2  0x00e51202 in BL_ConvertBlenderObjects(Main*, KX_Scene*, 
KX_KetsjiEngine*, e_PhysicsEngine, RAS_IRenderTools*, RAS_ICanvas*, 
KX_BlenderSceneConverter*, bool) ()
#3  0x00e59070 in KX_BlenderSceneConverter::ConvertScene(KX_Scene*, 
RAS_IRenderTools*, RAS_ICanvas*) ()
#4  0x00ec99e1 in KX_KetsjiEngine::CreateScene(Scene*) ()
#5  0x00eca5f0 in KX_KetsjiEngine::AddScheduledScenes() ()
#6  0x00eca7d0 in KX_KetsjiEngine::ProcessScheduledScenes() ()
#7  0x00ecae08 in KX_KetsjiEngine::NextFrame() ()
#8  0x00e44d7a in StartKetsjiShell ()
#9  0x008344ec in game_engine_exec ()
#10 0x007808bb in wm_operator_invoke ()
#11 0x007863ac in WM_init_game ()
#12 0x007752b1 in main ()

Best regards,
--Edwin



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

Bug#674330: clamav: FTBFS: llvm/lib/ExecutionEngine/JIT/Intercept.cpp:69:67: error: 'lseek64' was not declared in this scope

[Török Edwin]

On 2012-05-24 12:30, Lucas Nussbaum wrote:
>> llvm/lib/ExecutionEngine/JIT/Intercept.cpp: In constructor 
>> '{anonymous}::StatSymbols::StatSymbols()':
>> llvm/lib/ExecutionEngine/JIT/Intercept.cpp:69:67: error: 'lseek64' was not 
>> declared in this scope
>> make[6]: *** [Intercept.lo] Error 1

This is fixed in git already, feel free to cherry-pick:

http://git.clamav.net/gitweb?p=clamav-devel.git;a=patch;h=c609c8ea0409b2882aa3e6ef4dc48c210cf2d292;hp=aef065e18c5da11cabed9d74de1eb98762d6b952

Best regards,
--Edwin



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

Bug#671997: [texlive-latex-recommended] koma-script/scrguien.pdf: some broken references

[Török Edwin]

On 2012-05-09 01:32, Norbert Preining wrote:
> On Di, 08 Mai 2012, Török Edwin wrote:
>> "The latter is explained in the expert section of this document in ?? from 
>> ?? onwards."
>>
>> FWIW its the same on CTAN, so its likely a problem with the original 
>> document:
>> ftp://www.ctan.org/ctan/macros/latex/contrib/koma-script/scrguien.pdf
> 
> Thanks, if you find time, please report it to the up-upstream author
> Markus Kohm so that he can fix it in an upcoming release.
> 

Just checked again, and this appears to be fixed already in Koma script 3.11 
(20120515).

--Edwin



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

Bug#670954: [apt] MultiArch: apt-get -f install doesn't see correct dependency of package

[Török Edwin]

Package: apt
Version: 0.9.2
Severity: normal

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

'apt-get -f install' won't install libgcc1-dbg 4.7.0-6, although its available.
For some reason it thinks that it depends on gcc-4.7-base=4.7.0-5, which 
results in a conflict (gcc-4.7-base is 4.7.0-6 already).

I checked the control file in the .deb, it says gcc-4.7-base=4.7.0-6, so I 
don't know why its looking for -5.
Maybe it wants to run the postrm from 4.7.0-5 (but then shouldn't it ignore 
dependencies for that?).
Anyway all gcc-related packages seem to have a 4.7.0-6 version now, so 'apt-get 
-f install' should
be able to fix whatever the problem is, but it can't (see below).

Version 4.7.0-6 is available for libgcc1-dbg:
$ apt-cache policy libgcc1-dbg:amd64
libgcc1-dbg:
  Installed: 1:4.7.0-5
  Candidate: 1:4.7.0-6
  Version table:
 1:4.7.0-6 0
500 http://iota.nren.ro/debian/ unstable/main amd64 Packages
 *** 1:4.7.0-5 0
500 http://ftp.lug.ro/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
 1:4.7.0-3 0
500 http://iota.nren.ro/debian/ testing/main amd64 Packages

The :i386 is not installed:
$ apt-cache policy libgcc1-dbg:i386
libgcc1-dbg:i386:
  Installed: (none)
  Candidate: 1:4.7.0-5
  Version table:
 1:4.7.0-5 0
500 http://iota.nren.ro/debian/ unstable/main i386 Packages
500 http://ftp.lug.ro/debian/ unstable/main i386 Packages
 1:4.7.0-3 0
500 http://iota.nren.ro/debian/ testing/main i386 Packages



# apt-get install libgcc1-dbg:amd64=1:4.7.0-6
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  anjuta-common gtkpod-data id3v2 libanjuta-3-0 libgdl-3-2 libgdl-3-common
Use 'apt-get autoremove' to remove them.
The following packages will be upgraded:
  libgcc1-dbg
1 upgraded, 0 newly installed, 0 to remove and 62 not upgraded.
2 not fully installed or removed.
Need to get 0 B/101 kB of archives.
After this operation, 0 B of additional disk space will be used.
Traceback (most recent call last):
  File "/usr/bin/apt-listchanges", line 237, in 
main()
  File "/usr/bin/apt-listchanges", line 48, in main
debs = apt_listchanges.read_apt_pipeline(config)
  File "/usr/share/apt-listchanges/apt_listchanges.py", line 83, in 
read_apt_pipeline
return map(lambda pkg: filenames[pkg], order)
  File "/usr/share/apt-listchanges/apt_listchanges.py", line 83, in 
return map(lambda pkg: filenames[pkg], order)
KeyError: 'libgcc1-dbg'
dpkg: dependency problems prevent configuration of libgcc1-dbg:amd64:
 libgcc1-dbg:amd64 depends on gcc-4.7-base (= 4.7.0-5); however:
  Version of gcc-4.7-base:amd64 on system is 4.7.0-6.
 libgcc1-dbg:amd64 depends on libgcc1 (= 1:4.7.0-5); however:
  Version of libgcc1:amd64 on system is 1:4.7.0-6.
dpkg: error processing libgcc1-dbg:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libstdc++6-4.7-dbg:amd64:
 libstdc++6-4.7-dbg:amd64 depends on libgcc1-dbg; however:
  Package libgcc1-dbg:amd64 is not configured yet.
dpkg: error processing libstdc++6-4.7-dbg:amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libgcc1-dbg:amd64
 libstdc++6-4.7-dbg:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Background: gcc-4.7-base:amd64 and :i386 had a problem with a .gz mismatch in 
4.7.0-5,
thats why I'm trying to use 'apt-get -f install' to fix that.

So first I did an 'apt-get -f install', which removed all the :i386 packages 
(will try to install them back later).
However it still didn't fix the problem completely:

# apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  anjuta-common gtkpod-data id3v2 libanjuta-3-0 libgdl-3-2 libgdl-3-common
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  cpp-4.7 g++-4.7 g++-4.7-multilib gcc-4.7 gcc-4.7-base gcc-4.7-multilib 
gccgo-4.7 lib32gcc1 lib32gomp1 lib32itm1 lib32mudflap0 lib32quadmath0 
lib32stdc++6
  libgcc1 libgcc1-dbg libgfortran3 libgo0 libgo0-dbg libgomp1 libitm1 
libmudflap0 libquadmath0 libstdc++6 libstdc++6-4.7-dbg libstdc++6-4.7-dev
Suggested packages:
  gcc-4.7-locales gcc-4.7-doc lib32stdc++6-4.7-dbg libmudflap0-4.7-dev 
libgomp1-dbg libitm1-dbg libquadmath0-dbg libmudflap0-dbg binutils-gold
  gccgo-4.7-doc
The following packages will be REMOVED:
  gcc-4.7-base:i386 libapt-pkg4.12:i386 libbz2-1.0:i386 libc6:i386 
libc6-i686:i386 libgcc1:i386 libstdc++6:i386 zlib1g:i386
The following packages will be upgraded:
  cpp-4.7 g++-4.7 g++-4.7-multilib gcc-4.7 gcc-4.7-base gcc-4.7-multilib 
gccgo-4.7 lib32gcc1 lib32gomp1 lib32itm1 lib32mudflap0 lib32quadmath0 
lib32stdc++6
  libgcc1 libgcc1-dbg li

Bug#670954: [apt] MultiArch: apt-get -f install doesn't see correct dependency of package

[Török Edwin]

On 05/03/2012 04:20 PM, Goswin von Brederlow wrote:
> Török Edwin  writes:
> 
>> Traceback (most recent call last):
>>   File "/usr/bin/apt-listchanges", line 237, in 
>> main()
>>   File "/usr/bin/apt-listchanges", line 48, in main
>> debs = apt_listchanges.read_apt_pipeline(config)
>>   File "/usr/share/apt-listchanges/apt_listchanges.py", line 83, in 
>> read_apt_pipeline
>> return map(lambda pkg: filenames[pkg], order)
>>   File "/usr/share/apt-listchanges/apt_listchanges.py", line 83, in 
>> return map(lambda pkg: filenames[pkg], order)
>> KeyError: 'libgcc1-dbg'
> 
> I think that is your actual problem. Something is broken with (your)
> apt-listchanges. Apt-listchanges is a hook run before installing
> packages and if any hook fails the installation is aborted. Try removing
> that temporary from your apt.conf.

In the end I fixed this by removing libgcc1-dbg and libstdc++6-4.7-dbg, and 
reinstalling them.
I can however still reproduce the problem by downgrading to the .deb in my 
/var/cache/apt, so I've
tried disabling apt-listchanges as you suggested:

# apt-get -f  install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  anjuta-common gtkpod-data id3v2 libanjuta-3-0 libgdl-3-2 libgdl-3-common
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libgcc1-dbg
The following packages will be upgraded:
  libgcc1-dbg
1 upgraded, 0 newly installed, 0 to remove and 97 not upgraded.
1 not fully installed or removed.
Need to get 0 B/101 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? Y
dpkg: dependency problems prevent configuration of libgcc1-dbg:amd64:
 libgcc1-dbg:amd64 depends on gcc-4.7-base (= 4.7.0-5); however:
  Version of gcc-4.7-base:amd64 on system is 4.7.0-7.
 libgcc1-dbg:amd64 depends on libgcc1 (= 1:4.7.0-5); however:
  Version of libgcc1:amd64 on system is 1:4.7.0-7.
dpkg: error processing libgcc1-dbg:amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libgcc1-dbg:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Didn't work.

I _think_ the problem occurs only if I have a removed, but not purged old 
version of libgcc1-dbg/gcc-4.7-base:i386.

So there are 2 bugs here:
1. 'apt-get -f install' can't recover on its own from .gz mismatches, if the 
:i386 package is removed, and at an older version.
One has to manually --purge the :i386 package, before the :amd64 one can be 
upgraded. IMHO removed packages shouldn't affect upgradability.
2. 'apt-get -f install' can't recover on its own from an 
unpacked-but-not-configured libgcc1-dbg that got stuck at an older version.
One has to remove the package, and reinstall it to fix this.

I think apt-get -f install should at least give hints to the user on what to 
try manually, and of course best would be if
it could figure out on its own how to fix these situations.

FWIW downgrading and upgrading just the amd64 packages works:
1. Downgrade to 4.7.0-6, just amd64 packages, :i386 packages are purged:
# dpkg -i /var/cache/apt/archives/libgcc1_1%3a4.7.0-6_amd64.deb 
/var/cache/apt/archives/gcc-4.7-base_4.7.0-6_amd64.deb 
/var/cache/apt/archives/libstdc++6_4.7.0-6_amd64.deb
/var/cache/apt/archives/libgcc1-dbg_1%3a4.7.0-6_amd64.deb
2. apt-get -f install restores it back again

This doesn't work (steps to reproduce this bug):

1. Install libgcc1-dbg:i386
#  apt-get install libgcc1-dbg:i386 libgcc1-dbg:amd64
2.  Remove it (but don't purge)
# apt-get remove libgcc1-dbg:i386

status is now:
dpkg -l libgcc1 libgcc1-dbg gcc-4.7-base
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
Description
+++-=-=-==
ii  gcc-4.7-base:amd644.7.0-7   GCC, 
the GNU Compiler Collection (base package)
ii  gcc-4.7-base:i386 4.7.0-7   GCC, 
the GNU Compiler Collection (base package)
ii  libgcc1:amd64 1:4.7.0-7 GCC 
support library
ii  libgcc1:i386  1:4.7.0-7 GCC 
support library
ii  libgcc1-dbg:amd64 1:4.7.0-7 GCC 
support library (debug symbols)


3. Downgrade to 4.7.0-6, just amd64 packages. (will fail due to mismatching 
versions):
# dpkg -i /var/cache/apt/archives/libgcc1_1%3a4.7.0-6_amd64.deb 
/var/cache/apt/archives/gcc-4.7-base_4.7.0-6_amd64.deb 
/var/cach

Bug#670954: [apt] MultiArch: apt-get -f install doesn't see correct dependency of package

[Török Edwin]

On 05/03/2012 07:47 PM, Török Edwin wrote:
> On 05/03/2012 04:20 PM, Goswin von Brederlow wrote:
>> Török Edwin  writes:
>>
>>> Traceback (most recent call last):
>>>   File "/usr/bin/apt-listchanges", line 237, in 
>>> main()
>>>   File "/usr/bin/apt-listchanges", line 48, in main
>>> debs = apt_listchanges.read_apt_pipeline(config)
>>>   File "/usr/share/apt-listchanges/apt_listchanges.py", line 83, in 
>>> read_apt_pipeline
>>> return map(lambda pkg: filenames[pkg], order)
>>>   File "/usr/share/apt-listchanges/apt_listchanges.py", line 83, in 
>>> return map(lambda pkg: filenames[pkg], order)
>>> KeyError: 'libgcc1-dbg'
>>
>> I think that is your actual problem. Something is broken with (your)
>> apt-listchanges. Apt-listchanges is a hook run before installing
>> packages and if any hook fails the installation is aborted. Try removing
>> that temporary from your apt.conf.
> 
> In the end I fixed this by removing libgcc1-dbg and libstdc++6-4.7-dbg, and 
> reinstalling them.
> I can however still reproduce the problem by downgrading to the .deb in my 
> /var/cache/apt, so I've
> tried disabling apt-listchanges as you suggested:
> 
> # apt-get -f  install
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Correcting dependencies... Done
> The following packages were automatically installed and are no longer 
> required:
>   anjuta-common gtkpod-data id3v2 libanjuta-3-0 libgdl-3-2 libgdl-3-common
> Use 'apt-get autoremove' to remove them.
> The following extra packages will be installed:
>   libgcc1-dbg
> The following packages will be upgraded:
>   libgcc1-dbg
> 1 upgraded, 0 newly installed, 0 to remove and 97 not upgraded.
> 1 not fully installed or removed.
> Need to get 0 B/101 kB of archives.
> After this operation, 0 B of additional disk space will be used.
> Do you want to continue [Y/n]? Y
> dpkg: dependency problems prevent configuration of libgcc1-dbg:amd64:
>  libgcc1-dbg:amd64 depends on gcc-4.7-base (= 4.7.0-5); however:
>   Version of gcc-4.7-base:amd64 on system is 4.7.0-7.
>  libgcc1-dbg:amd64 depends on libgcc1 (= 1:4.7.0-5); however:
>   Version of libgcc1:amd64 on system is 1:4.7.0-7.
> dpkg: error processing libgcc1-dbg:amd64 (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  libgcc1-dbg:amd64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Didn't work.
> 
> I _think_ the problem occurs only if I have a removed, but not purged old 
> version of libgcc1-dbg/gcc-4.7-base:i386.
> 
> So there are 2 bugs here:
> 1. 'apt-get -f install' can't recover on its own from .gz mismatches, if the 
> :i386 package is removed, and at an older version.
> One has to manually --purge the :i386 package, before the :amd64 one can be 
> upgraded. IMHO removed packages shouldn't affect upgradability.
> 2. 'apt-get -f install' can't recover on its own from an 
> unpacked-but-not-configured libgcc1-dbg that got stuck at an older version.
> One has to remove the package, and reinstall it to fix this.
> 
> I think apt-get -f install should at least give hints to the user on what to 
> try manually, and of course best would be if
> it could figure out on its own how to fix these situations.
> 
> FWIW downgrading and upgrading just the amd64 packages works:
> 1. Downgrade to 4.7.0-6, just amd64 packages, :i386 packages are purged:
> # dpkg -i /var/cache/apt/archives/libgcc1_1%3a4.7.0-6_amd64.deb 
> /var/cache/apt/archives/gcc-4.7-base_4.7.0-6_amd64.deb 
> /var/cache/apt/archives/libstdc++6_4.7.0-6_amd64.deb
> /var/cache/apt/archives/libgcc1-dbg_1%3a4.7.0-6_amd64.deb
> 2. apt-get -f install restores it back again
> 
> This doesn't work (steps to reproduce this bug):
> 
> 1. Install libgcc1-dbg:i386
> #  apt-get install libgcc1-dbg:i386 libgcc1-dbg:amd64
> 2.  Remove it (but don't purge)
> # apt-get remove libgcc1-dbg:i386
> 
> status is now:
> dpkg -l libgcc1 libgcc1-dbg gcc-4.7-base
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name  Version   
> Description
> +++-=-=-==
> ii  gcc-4.7-base:amd64  

Bug#796192: emacs24: crashes when loosing connection to X

[Török Edwin]

Package: emacs24
Version: 24.4+1-5
Severity: normal

Dear Maintainer,

   * What led up to the situation?

After I login to LXDE I usually find core files scattered in various
directories that I started emacs from, core files that were left by emacs.


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

Looking at the core file it seems to crash when loosing connection to X, so
probably when I logout while having emacs running.
I've seen it mentioned somewhere that this is a Gtk bug [1], however Emacs is
the only application that crashes this often, and I run plenty of other
applications that connect to X
and are running when I logout/shutdown, like Iceweasel, Icedove, Mate-terminal,
etc.

Looking at the stacktrace it looks like it receives the X disconnect event
(x_connection_closed) but then ends up calling redisplay_internal anyway which
now calls
emacs_abort because you can't access X objects anymore:

  if (FRAME_INITIAL_P (SELECTED_FRAME ())
  || !NILP (Vinhibit_redisplay))
return;

#define SELECTED_FRAME()\
 ((FRAMEP (selected_frame)  \
   && FRAME_LIVE_P (XFRAME (selected_frame)))   \
  ? XFRAME (selected_frame) \
  : (emacs_abort (), (struct frame *) 0))

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

$ gdb core -c /usr/bin/emacs24

   * What was the outcome of this action?

Core was generated by `emacs'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00330ce0f79b in raise (sig=sig@entry=6) at
.../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
37  ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb) bt
#0  0x00330ce0f79b in raise (sig=sig@entry=6) at
.../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x004e9fc6 in terminate_due_to_signal (sig=sig@entry=6,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:378
#2  0x005035d3 in emacs_abort () at sysdep.c:2131
#3  0x004513b1 in redisplay_internal () at xdisp.c:13485
#4  0x00452ef5 in redisplay_preserve_echo_area
(from_where=from_where@entry=13) at xdisp.c:14185
#5  0x005984e5 in Fdelete_process (process=60984333) at process.c:897
#6  0x0059eb75 in kill_buffer_processes (buffer=12315634) at
process.c:6947
#7  0x004e9d9f in shut_down_emacs (sig=sig@entry=0, stuff=12315634) at
emacs.c:2025
#8  0x004e9ee6 in Fkill_emacs (arg=arg@entry=60) at emacs.c:1952
#9  0x004e9fdc in terminate_due_to_signal (sig=15,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:360
#10 0x005023ae in handle_fatal_signal (sig=) at
sysdep.c:1630
#11 0x005031bd in deliver_process_signal (sig=15, handler=0x5023a0
) at sysdep.c:1570
#12 
#13 0x00330ce0f79b in raise (sig=15) at ../nptl/sysdeps/unix/sysv/linux/pt-
raise.c:37
#14 0x003453e05dc0 in ffi_call_unix64 () from /usr/lib/x86_64-linux-
gnu/libffi.so.6
#15 0x003453e05828 in ffi_call () from /usr/lib/x86_64-linux-
gnu/libffi.so.6
#16 0x003e38610ebc in g_cclosure_marshal_generic_va (closure=0x14cb760,
return_value=0x0, instance=0x14cd0a0, args_list=,
marshal_data=0x3e382c86b0 , n_params=2,
param_types=0x14cb7d0) at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:1541
#17 0x003e38610474 in _g_closure_invoke_va (closure=0x5c59,
closure@entry=0x14cb760, return_value=0x5c59, return_value@entry=0x0,
instance=0xf,
instance@entry=0x14cd0a0, args=0x330ce0f79b ,
args@entry=0x7fffb211e140, n_params=792500800,
param_types=0x345264b9fa <_IO_vfprintf_internal+22490>) at
/tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
#18 0x003e3862a087 in g_signal_emit_valist (instance=0x14cd0a0,
signal_id=, detail=0, var_args=var_args@entry=0x7fffb211e140)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
#19 0x003e3862a9df in g_signal_emit (instance=,
signal_id=, detail=detail@entry=0)
at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
#20 0x003e382c70a5 in emit_closed_in_idle (user_data=0x7f5620009cd0) at
/tmp/buildd/glib2.0-2.42.1/./gio/gdbusconnection.c:1386
#21 0x003e37649b6d in g_main_dispatch (context=0x1466bd0) at
/tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3111
#22 g_main_context_dispatch (context=context@entry=0x1466bd0) at
/tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3710
#23 0x003e37649f48 in g_main_context_iterate
(context=context@entry=0x1466bd0, block=block@entry=1,
dispatch=dispatch@entry=1, self=)
at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3781
#24 0x003e37649ffc in g_main_context_iteration (context=0x1466bd0,
may_block=1) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3842
#25 0x003e3b7ebc95 in gtk_main_iteration () from /usr/lib/x86_64-linux-
gnu/libgtk-3.so.0
#26 0x004bd942 in XTread_socket (terminal=,
hold_quit=0x7fffb211e380) at xterm.c:7016
#27 0x004f1031 in gobble_input () at keyboard.c:6850
#28 0x004f08f5 in handle_async_input () at keyboard.c:7090
#29 proces

Bug#840175: sx: new upstream: SX 2.2

[Török Edwin]

On 2016-11-13 21:57, László Böszörményi (GCS) wrote:
> Hi Edwin,
> 
> On Sun, Oct 9, 2016 at 10:39 AM, Török Edwin  wrote:
>> A new upstream version is available: SX-2.2. See 
>> http://blog.skylable.com/2016/09/sx-2-2-release/

>  Sorry for the very slow reaction. :( I've packaged SX 2.2 now,

Thanks, FWIW there might be an SX 2.3 soon too.

> including the fix for OpenSSL 1.1 - but the self-tests are failing
> (relevant parts hopefully):
> FAIL: test/run-nginx-test.sh
> [...]
> + /root/compile/sx/sx-2.2+ds/server/sx-test-AieIoBQg/sbin/sxadm
> cluster --new --batch-mode
> --node-dir=/root/compile/sx/sx-2.2+ds/server/sx-test-AieIoBQg/var/lib/sxserver/data
> 6G/127.0.0.1 sx://localhost
> lt-sxadm: [qlog]: SQLite result 0x7: sem_open() - errno 38

Do you have /dev/shm mounted? That used to be the culprit for these errors.

Best regards,
-- 
Edwin Török | Co-founder and Lead Developer

Skylable open-source object storage: reliable, fast, secure
http://www.skylable.com

Bug#840175: Fwd: [sx-users] SX 2.3 released

[Török Edwin]

retitle 840175 sx: new upstream: SX 2.3
thanks

SX 2.3 just got released: http://cdn.skylable.com/source/sx-2.3.tar.gz

Please let me know if you encounter any problems during packaging.


 Forwarded Message 
Subject: [sx-users] SX 2.3 released
Date: Wed, 16 Nov 2016 16:31:34 +0100
From: Alberto Wu 
Reply-To: sx-users 
To: sx-users 

Folks,

The latest SX version 2.3 was just released.

In the core, focus was mostly on mitigating the effects of background
jobs on regular cluster operations.
In particular the garbage collector has undergone a major rework and you
should no longer experience load spikes and temporary node unavailability.

Performance in SXFS was further improved with the introduction of a
second layer of cache for frequently accessed objects.

Some changes also affect the binary packages:
- New packages available for Fedora 23 and 24
- New packages available for Ubuntu Xenial and Yakkety
- Packages for CentOS 5 are no longer provided due to lack of sha256
signature support
- Packages for Fedora 20 and 21 are no longer provided due to EOL
- Packages for Ubuntu Utopic and Vivid are no longer provided due to EOL

Download and installation instructions can be found at:
https://www.skylable.com/products/sx/install

Thanks,

—
The Skylable team (dev-t...@skylable.com)

Follow us on twitter: @skylable
Like us on facebook: http://fb.com/skylable
Connect to us on linkedin: http://linkedin.com/company/skylable

___
http://lists.skylable.com/listinfo/sx-users

Bug#840175: [sx-users] SX 2.3 released

[Török Edwin]

On 2016-11-16 21:41, László Böszörményi (GCS) wrote:
> On Wed, Nov 16, 2016 at 4:38 PM, Török Edwin  wrote:
>> SX 2.3 just got released: http://cdn.skylable.com/source/sx-2.3.tar.gz
>  Thanks for the heads-up!
> 
>> Please let me know if you encounter any problems during packaging.
>  I'm thinking about the best approach of doing the upgrade during the
> package upgrade. I've a test path, but not tried it yet if it works.
> :( Now I first need to update the proposed package to 2.3 first, then
> do the testing.

I tried something like the patch below but I'm not entirely happy with it 
either,
I hope you'll be able to find a better solution.

I had two problems: switching from init scripts to systemd, and having to 
restart SX twice running the upgrade.
Handling the upgrade used to be a lot easier when systemd was not involved.

--- a/server/sxscripts/sbin/sxserver.in 2015-02-13 13:50:32.0 +0200
+++ b/server/sxscripts/sbin/sxserver.in 2015-02-13 15:54:09.804283967 +0200
@@ -13,6 +13,12 @@
 echo "No permission to read $CONFIG"
 exit 1
 fi
+if [ "$1" = "oldstop" ]; then
+ set -- "stop"
+elif [ `id -u` -eq 0 -a -x /bin/systemctl ]; then
+   exec /bin/systemctl "$1" sxserver.service
+fi
+

sx.postinst:

case "$1" in
configure)
# Noop if no upgrade is needed
if [ -f /etc/sxserver/sxsetup.conf ]; then
# stop with old init script (the systemd unit for some reason 
doesn't work for stopping a service started by the init script)
/usr/sbin/sxserver oldstop
# run upgrade, this leaves the server in running state
/usr/sbin/sxsetup --upgrade
# have to stop it again here, cause debhelper scripts below would 
try to start it and fail if its already started.
/usr/sbin/sxserver stop
fi
;;
.


Best regards,

Bug#808119: bugreport doesn't show up on bugs.debian.org and no error messages

[Török Edwin]

Package: bugs.debian.org
Severity: wishlist

Dear Maintainer,

I've sent a bugreport based on 'reportbug --template sx' output, but it hasn't 
shown up on bugs.debian.org/sx.
(I've forwarded the mail manually to the maintainer, and that one was received 
and answered).

See the bugreport.eml attachment for the report I've sent: it contains a 
'Source:' and no 'Version:' (running reportbug by hand says that a blank 
Version is fine,
and it is actually what I wanted because the bug is a wishlist about a new 
upstream version).
It also has a signature added by my MUA.

What am I doing wrong?

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

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

-- 
Edwin Török | Co-founder and Lead Developer

Skylable open-source object storage: reliable, fast, secure
http://www.skylable.com


bugreport.eml
Description: application/extension-eml

Bug#794409: os-prober: generic detection using /etc/os-release (for Void Linux and NixOS)

[Török Edwin]

Package: os-prober
Version: 1.65
Severity: normal
Tags: patch

Dear Maintainer,

os-prober correctly detects Fedora 22, however it doesn't detect Void Linux or
NixOS (they are reported as unknown Linux distribution).

Actual os-prober 1.65 output:
/dev/mapper/os-fedora_root:Fedora release 22 (Twenty Two):Fedora:linux
/dev/mapper/os-void_root:unknown Linux distribution:Linux:linux

Expected output:
/dev/mapper/os-fedora_root:Fedora release 22 (Twenty Two):Fedora:linux
/dev/mapper/os-nixos_root:NixOS 14.12.801.221101a (Caterpillar):NixOS:linux
/dev/mapper/os-void_root:Void Linux:Void:linux

Both of these have an /etc/os-release file, and using the patch below allows
update-grub2 to generate the expected names.

--- a/usr/lib/os-probes/mounted/90linux-distro  2014-09-29 00:04:17.0
+0300
+++ b/usr/lib/os-probes/mounted/90linux-distro  2015-08-02 21:51:46.911231870
+0300
@@ -17,7 +17,7 @@
 # symlinks we need to also check in $dir/usr/lib* for distributions that
 # moved /lib* to /usr and only left symlinks behind.
 # TODO: look for ld-linux.so on arches that have it
-if (ls "$dir"/lib*/ld*.so* || ls "$dir"/usr/lib*/ld*.so*) >/dev/null
2>/dev/null; then
+if (ls "$dir/etc/os-release" || ls "$dir"/lib*/ld*.so* || ls
"$dir"/usr/lib*/ld*.so*) >/dev/null 2>/dev/null; then
if [ -e "$dir/etc/debian_version" ]; then
short="Debian"
long="$(printf "Debian GNU/Linux (%s)\n" "$(cat
"$dir/etc/debian_version")")"
@@ -125,6 +125,9 @@
elif [ -e "$dir/etc/meego-release" ]; then
short="MeeGo"
long="$(head -1 "$dir/etc/meego-release")"
+   elif [ -e "$dir/etc/os-release" ]; then
+   short=$(cat $dir/etc/os-release|grep ^NAME=|cut -f2 -d=|cut -f2
-d\")
+   long=$(cat $dir/etc/os-release|grep ^PRETTY_NAME=|cut -f2
-d=|cut -f2 -d\")
else
short="Linux"
long="unknown Linux distribution"



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

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

Versions of packages os-prober depends on:
ii  libc6  2.19-18

os-prober recommends no packages.

os-prober 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#776850: RFP: sx -- Scalable public and private cloud storage

[Török Edwin]

On Mon, 2 Feb 2015 15:15:33 +0100 
=?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:
>  As previously noted, I'm intend to package it. Going to check the
> pull request over my old packaging. The source was monolithic in the
> past, but as I've read, it was resolved.


New upstream version SX 1.2 available:
https://github.com/gcsideal/sx-debian/pull/3

It renames libsx to libsxclient to avoid the conflict with the already existing 
libsx-dev package.

I think the package should be good for Debian now.
Are there any other blockers?

Thanks,
--Edwin


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

Bug#754932: RFP: tiptop -- display hardware performance counters for Linux tasks

[Török Edwin]

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

--- Please fill out the fields below. ---

   Package name: tiptop
Version: 2.2
Upstream Author: Erven Rohou 
URL: http://tiptop.gforge.inria.fr/
License: GPLv2
Description: (from the website and README)

Tiptop is a performance monitoring tool for Linux.  It provides a
dynamic real-time view of the tasks running in the system. Tiptop is
very similar to the top utility, but most of the information displayed
comes from hardware counters.

Features:
No root privilege needed
No patch to OS
No module to load
No need to instrument applications
No need to even restart applications
Any event supported by the hardware
some predefined: instructions, cycles, LLC misses (easy)
any hardware supported event (slightly harder)
Live mode and batch mode
Configure file to define counters and screens
Pretty much like top


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

Bug#754984: [libpam-systemd] any news?

[Török Edwin]

Package: libpam-systemd
Version: 204-14

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

Now that a new cgmanager is in unstable and the bugs closed (except one marked 
as 'harmless')
what else needs to happen to get libpam-systemd and sysvinit-core installable?

For now I have this in my /etc/apt/preferences.d/nosystemd:
Package: systemd-sysv
Pin: origin ""
Pin-Priority: -1

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.14-2-amd64

Debian Release: jessie/sid
  500 unstableftp.ro.debian.org 
  500 testing ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-==
libc6  (>= 2.14) | 
libcap2(>= 2.10) | 
libdbus-1-3   (>= 1.0.2) | 
libpam0g   (>= 0.99.7.1) | 
systemd   (= 204-14) | 
libpam-runtime  (>= 1.0.1-6) | 
systemd-sysv | 
 OR systemd-shim | 


Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#750821: sweethome3d crashes when selecting "Preferences"

[Török Edwin]

Package: sweethome3d
Version: 4.5+dfsg-3
Followup-For: Bug #750821

Dear Maintainer,

This problem is documented in the FAQ "Sweet Home 3D crashes when I want to
edit preferences, print, create a photo or create a video. What can I do?":
http://www.sweethome3d.com/faq.jsp

Using the workaround there I have edited JAVA_ARGS in /usr/bin/sweethome3d and
added
-Dcom.eteks.sweethome3d.j3d.checkOffScreenSupport=false.
Now it no longer crashes:

JAVA_ARGS="-Djava.library.path=/usr/lib/jni \
 -Dcom.eteks.sweethome3d.j3d.checkOffScreenSupport=false \
-Dcom.eteks.sweethome3d.applicationFolders=$HOME/.eteks/sweethome3d:/usr/share/sweethome3d"

FWIW my OpenGL driver is:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.3.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.3.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:




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

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

Versions of packages sweethome3d depends on:
ii  default-jre [java6-runtime] 2:1.7-52
ii  icedtea-netx-common 1.5-2+deb8u1
ii  java-wrappers   0.1.28
ii  libbatik-java   1.7+dfsg-5
ii  libfreehep-graphicsio-svg-java  2.1.1-3
ii  libitext-java   2.1.7-9
ii  libjava3d-java  1.5.2+dfsg-11
ii  libsunflow-java 0.07.2.svn396+dfsg-13
ii  openjdk-6-jre [java6-runtime]   6b35-1.13.7-1
ii  openjdk-7-jre [java6-runtime]   7u79-2.5.5-1~deb8u1

Versions of packages sweethome3d recommends:
ii  sweethome3d-furniture  1.4.2-1

sweethome3d 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#790498: iceweasel: upgrading from jessie makes all passwords in the password manager invalid

[Török Edwin]

On 07/13/2015 01:46 AM, Mike Hommey wrote:
> On Mon, Jun 29, 2015 at 11:28:02PM +0300, Török Edwin wrote:
>> Package: iceweasel
>> Version: 38.0.1-5
>> Severity: grave
>> Justification: causes non-serious data loss
>>
> 
> Your comment in upstream bug says that forcing a new upgrade of the
> signons store worked, so it's really not clear what went wrong the first
> time.

One possibility is that I upgraded from the Jessie version of firefox to the 
unstable one in the past to test something, which upgraded the password store 
to the new format at that time.
Then when I was done testing that site I downgraded back to the stable version 
in Jessie, and added/changed more passwords as usual, but that updated the 
passwords in the old store.

Now when I tried to upgrade again to the version in unstable it used the 
out-of-date signons store that it converted some time ago, and any changes made 
by the old firefox version haven't been taken into account.
That might explain why Firefox from unstable has seen less passwords than the 
Jessie version, and why none of them worked anymore (I changed them all using 
the old version of firefox).

If you think it'd be useful I can try to reproduce this with a fresh firefox 
profile and upgrading/downgrading while changing passwords.
Not sure what could be done to fix this, one way would to provide a button to 
import the passwords from the old store (even if it has been imported in the 
past already), and if their last changed time is newer than
the password in the new store use that, or just have both available and allow 
the user to choose and delete the outdated one.


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

Bug#702349: lintian should not complain about hardening for package written in pure Ocaml

[Török Edwin]

On Mon, 03 Feb 2014 17:42:35 +0100 =?ISO-8859-1?Q?St=E9phane_Glondu?= 
 wrote:
> Le 06/01/2014 16:24, Moritz Muehlenhoff a écrit :
> >> Le 05/03/2013 16:35, Niels Thykier a écrit :
> >>> Does ELF binaries produced by "pure" Ocaml have any distinct feature
> >>> that can be used to tell them apart from any other ELF binary?
> >>
> >> ELF binaries produced by the OCaml compiler always include a bit of C
> >> code (the runtime), so they are never actually "pure".
> >>
> >> I don't think that the lintian tag (whatever its level) should be
> >> removed at the moment. I am not planning to have a deeper looker at this
> >> issue before next release or next debconf, though.
> > 
> > Could you please add a note to https://wiki.debian.org/HardeningWalkthrough
> > that while Ocaml packages produce ELF binaries they are not covered by
> > the hardening effort?
> 
> I just did that.
> 
> BTW, the OCaml build system is quite messy and it will take longer than
> expected to "fix" it for hardening...
> 

The attached patch fixes some of the relro lintian warnings for the executables 
themselves, but these still remain for the .cmxs,.so and objinfo_helper:

W: ocaml-base: hardening-no-relro usr/lib/ocaml/graphics.cmxs
W: ocaml-base: hardening-no-relro usr/lib/ocaml/stublibs/dllgraphics.so
W: ocaml-nox: hardening-no-relro usr/lib/ocaml/objinfo_helper
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/bigarray.cmxs
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/nums.cmxs
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/str.cmxs
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/stublibs/dllbigarray.so
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/stublibs/dllcamlstr.so
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/stublibs/dllnums.so
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/stublibs/dllthreads.so
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/stublibs/dllunix.so
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/stublibs/dllvmthreads.so
W: ocaml-base-nox: hardening-no-relro usr/lib/ocaml/unix.cmxs

FWIW 'hardening-check ocamlopt.opt' now says:
ocamlopt.opt:
 Position Independent Executable: no, normal executable!
 Stack protected: no, not found!
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes


Although perhaps it'd be better to patch configure to include CCLINKFLAGS in 
$nativecclinkopts, in objinfo_helper's build command, and in the flag used for 
linking .so and .cmxs
(haven't found its name yet though). What do you think?

diff -ru ../o/ocaml-4.02.1/debian/rules debian/rules
--- ../o/ocaml-4.02.1/debian/rules	2015-02-16 12:37:56.0 +0200
+++ debian/rules	2015-07-15 12:39:58.477250079 +0300
@@ -59,12 +59,18 @@
 export OCAML_OPT_ARCH
 export OCAML_STDLIB_DIR
 
+export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
+LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
+# for ocamlyacc
+export CCLINKFLAGS=$(LDFLAGS)
+
 CONFIGURE_OPTS := \
   --host $(DEB_BUILD_GNU_TYPE)\
   --with-pthread -prefix $(DEB_TEST_BUILD_PREFIX)/usr \
   -libdir $(DEB_TEST_BUILD_PREFIX)$(OCAML_STDLIB_DIR) \
   -x11lib "$(shell pkg-config --variable=libdir x11)" \
   -mandir $(DEB_TEST_BUILD_PREFIX)/usr/share/man \
+  -dllibs "$(LDFLAGS)"
 
 CONFIGURE_SED := \
   -e "/LIBBFD_LINK/s%-lbfd%-Wl,-Bstatic -lbfd -Wl,-Bdynamic%" \

Bug#792502: ocaml: obey hardening LDFLAGS

[Török Edwin]

Package: ocaml
Version: 4.01.0-5
Severity: minor
Tags: patch

Dear Maintainer,

See discussion on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702349

I am including a patch that enables the relro and bindnow hardening flags for
OCaml and packages compiled by ocaml.

I haven't submitted the patch upstream yet, there is only this bugreport asking
for LDFLAGS and having CCLINKFLAGS as solution for ocamlyacc only:
http://caml.inria.fr/mantis/view.php?id=4698
There is also this bug about CFLAGS (which can be useful for hardening C stubs
perhaps?):
http://caml.inria.fr/mantis/view.php?id=3664

My patch simply sets CCLINKFLAGS based on LDFLAGS and includes CCLINKFLAGS into
MKEXE/MKDLL/MKMAINDLL, which AFAICT
are the cmdlines used to build executables and shared libraries by
ocamlc/ocamlopt.

Should I submit the patch upstream, or would it require more modifications to
support Debian's hardening features?

Output of hardening-check before the patch:
/usr/bin/ocamlopt.opt:
 Position Independent Executable: no, normal executable!
 Stack protected: no, not found!
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: no, not found!
 Immediate binding: no, not found!

Output of hardening-check after the patch:
../ocamlopt.opt:
 Position Independent Executable: no, normal executable!
 Stack protected: no, not found!
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

Running lintian on the newly built packages don't show the hardening-no-relro
warning anymore:
$ lintian ../*.deb
W: ocaml-nox: binary-without-manpage usr/bin/ocamlbuild
W: ocaml-mode: binary-without-manpage usr/bin/ocamltags
N: 1 tag overridden (1 warning)



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

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

Versions of packages ocaml depends on:
ii  libx11-dev  2:1.6.2-3
ii  ocaml-base [ocaml-base-4.01.0]  4.01.0-5
ii  ocaml-base-nox  4.01.0-5
ii  ocaml-nox [ocaml-nox-4.01.0]4.01.0-5

ocaml recommends no packages.

Versions of packages ocaml suggests:
ii  tcl-dev  8.6.0+8
pn  tk-dev   

-- no debconf information
--- a/debian/patches/0010-Obey-ldflags.patch	1970-01-01 02:00:00.0 +0200
+++ b/debian/patches/0010-Obey-ldflags.patch	2015-07-15 15:59:20.600661858 +0300
@@ -0,0 +1,34 @@
+Description: use CCLINKFLAGS for linking all executables and shared libraries
+ This allows packagers to set additional linker flags for executables and shared
+ libraries created by OCaml, and for the OCaml tools themselves.
+ OCaml code can be linked with various C stubs and C libraries that would
+ benefit from using hardening link flags, such as -Wl,-z,relro.
+---
+
+Origin: other
+Bug-Debian: https://bugs.debian.org/702349
+Forwarded: no
+Last-Update: <2015-07-15>
+
+--- ocaml-4.02.1.orig/configure
 ocaml-4.02.1/configure
+@@ -739,6 +739,8 @@ if test $with_sharedlibs = "yes"; then
+   shared_libraries_supported=true;;
+   esac
+ fi
++mksharedlib="$mksharedlib $CCLINKFLAGS"
++mkexe="$mkexe $CCLINKFLAGS"
+ 
+ if test -z "$mkmaindll"; then
+   mkmaindll=$mksharedlib
+--- ocaml-4.02.1.orig/tools/Makefile.shared
 ocaml-4.02.1/tools/Makefile.shared
+@@ -278,7 +278,7 @@ beforedepend:: opnames.ml
+ 
+ objinfo_helper$(EXE): objinfo_helper.c ../config/s.h
+ 	$(BYTECC) -o objinfo_helper$(EXE) $(BYTECCCOMPOPTS) \
+-  objinfo_helper.c $(LIBBFD_LINK)
++  objinfo_helper.c $(LIBBFD_LINK) $(CCLINKFLAGS)
+ 
+ OBJINFO=../compilerlibs/ocamlcommon.cma \
+ ../compilerlibs/ocamlbytecomp.cma \
diff -rNu ../o/ocaml-4.02.1/debian/patches/series debian/patches/series
--- a/debian/patches/series	2014-11-20 17:48:56.0 +0200
+++ b/debian/patches/series	2015-07-15 16:07:10.622247953 +0300
@@ -7,3 +7,4 @@
 0007-Tune-resource-usage-of-some-tests.patch
 0008-Native-backtraces-don-t-work-on-powerpc-and-sparc.patch
 0009-Fix-asmcomp-tests-on-sparc.patch
+0010-Obey-ldflags.patch
--- a/debian/rules	2015-02-16 12:37:56.0 +0200
+++ b/debian/rules	2015-07-15 15:54:11.360881817 +0300
@@ -59,6 +59,9 @@
 export OCAML_OPT_ARCH
 export OCAML_STDLIB_DIR
 
+export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
+export CCLINKFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
+
 CONFIGURE_OPTS := \
   --host $(DEB_BUILD_GNU_TYPE)\
   --with-pthread -prefix $(DEB_TEST_BUILD_PREFIX)/usr \

Bug#702349: Info received (Bug#702349: lintian should not complain about hardening for package written in pure Ocaml)

[Török Edwin]

block 702349 by 792502
Thanks

Updated patch attached, all the hardening-no-relro warnings are gone now.
I've opened a bug for the ocaml package.
--- a/debian/patches/0010-Obey-ldflags.patch	1970-01-01 02:00:00.0 +0200
+++ b/debian/patches/0010-Obey-ldflags.patch	2015-07-15 15:59:20.600661858 +0300
@@ -0,0 +1,34 @@
+Description: use CCLINKFLAGS for linking all executables and shared libraries
+ This allows packagers to set additional linker flags for executables and shared
+ libraries created by OCaml, and for the OCaml tools themselves.
+ OCaml code can be linked with various C stubs and C libraries that would
+ benefit from using hardening link flags, such as -Wl,-z,relro.
+---
+
+Origin: other
+Bug-Debian: https://bugs.debian.org/702349
+Forwarded: no
+Last-Update: <2015-07-15>
+
+--- ocaml-4.02.1.orig/configure
 ocaml-4.02.1/configure
+@@ -739,6 +739,8 @@ if test $with_sharedlibs = "yes"; then
+   shared_libraries_supported=true;;
+   esac
+ fi
++mksharedlib="$mksharedlib $CCLINKFLAGS"
++mkexe="$mkexe $CCLINKFLAGS"
+ 
+ if test -z "$mkmaindll"; then
+   mkmaindll=$mksharedlib
+--- ocaml-4.02.1.orig/tools/Makefile.shared
 ocaml-4.02.1/tools/Makefile.shared
+@@ -278,7 +278,7 @@ beforedepend:: opnames.ml
+ 
+ objinfo_helper$(EXE): objinfo_helper.c ../config/s.h
+ 	$(BYTECC) -o objinfo_helper$(EXE) $(BYTECCCOMPOPTS) \
+-  objinfo_helper.c $(LIBBFD_LINK)
++  objinfo_helper.c $(LIBBFD_LINK) $(CCLINKFLAGS)
+ 
+ OBJINFO=../compilerlibs/ocamlcommon.cma \
+ ../compilerlibs/ocamlbytecomp.cma \
diff -rNu ../o/ocaml-4.02.1/debian/patches/series debian/patches/series
--- a/debian/patches/series	2014-11-20 17:48:56.0 +0200
+++ b/debian/patches/series	2015-07-15 16:07:10.622247953 +0300
@@ -7,3 +7,4 @@
 0007-Tune-resource-usage-of-some-tests.patch
 0008-Native-backtraces-don-t-work-on-powerpc-and-sparc.patch
 0009-Fix-asmcomp-tests-on-sparc.patch
+0010-Obey-ldflags.patch
--- a/debian/rules	2015-02-16 12:37:56.0 +0200
+++ b/debian/rules	2015-07-15 15:54:11.360881817 +0300
@@ -59,6 +59,9 @@
 export OCAML_OPT_ARCH
 export OCAML_STDLIB_DIR
 
+export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
+export CCLINKFLAGS=$(shell dpkg-buildflags --get LDFLAGS)
+
 CONFIGURE_OPTS := \
   --host $(DEB_BUILD_GNU_TYPE)\
   --with-pthread -prefix $(DEB_TEST_BUILD_PREFIX)/usr \

Bug#788421: virtaal: amagama not working ,need to follow redirects

[Török Edwin]

Package: virtaal
Version: 0.7.1-1
Severity: normal
Tags: patch

Dear Maintainer,

I was trying to use virtaal to translate some .po/.ts files,
however the amagama plugin didn't work.
Wireshark revealed that it was getting 301 responses, and it wasn't following
these redirects.

Upstream has already fixed the issue here:
https://github.com/translate/virtaal/commit/64f6a16c879e7d08ba80bd1f469ffcee2f843257

If I patch /usr/share/pyshared/virtaal/support/httpclient.py then amagama works
again.



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

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

Versions of packages virtaal depends on:
ii  python 2.7.9-1
ii  python-glade2  2.24.0-4
ii  python-gobject 3.14.0-1
ii  python-gtk22.24.0-4
ii  python-lxml3.4.0-1
ii  python-pycurl  7.19.5-3
ii  python2.7  2.7.9-2
ii  translate-toolkit  1.12.0+dfsg1-2

Versions of packages virtaal recommends:
ii  libreoffice-common  1:4.3.3-2+deb8u1
ii  python-gtkspell 2.25.3-13
ii  python-levenshtein  0.11.2-2
ii  python-psycopg2 2.5.4+dfsg-1

virtaal 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#563335: [fgetty]

[Török Edwin]

Package: fgetty
Version: 0.6-5

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

FWIW building checkpassword using musl-gcc instead of dietlibc would support 
this.
Unfortunately login.c doesn't build with musl-gcc due to __ltostr() which is 
only present in dietlibc.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.0
  500 testing-updates ftp.ro.debian.org 
  500 testing security.debian.org 
  500 testing ftp.ro.debian.org 
  100 jessie-backports ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#708209: [virt-manager] got same error message

[Török Edwin]

Package: virt-manager
Version: 1:1.0.1-3

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

When logged in to KDE virt-manager works: I can connect to the running VM's 
console.
But when I log in to the MATE desktop I get the same error message as in this 
(old) bugreport:
Error: viewer connection to hypervisor got refused or disconnected!

I tried installing consolekit, but it didn't help. How do I get virt-viewer 
working in MATE?

I have created the VM using virt-manager in MATE, but it cannot connect the 
viewer when trying to use the qemu:///system connection.
If I reboot into Xen and use the xen:// connection that works in MATE too (for 
Xen VMs).

Running virt-viewer with sudo works.

My user is in the libvirt group, is another group required?
uid=1000(edwin) gid=1000(edwin) 
groups=1000(edwin),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),45(sasl),46(plugdev),103(netdev),110(lpadmin),113(scanner),128(libvirt),131(wireshark)

Also 'virsh list' shows an empty list:
 IdName   State


Whereas 'sudo virsh list' shows:
 IdName   State

 4 debianwheezy   running


See the attached domain xml.


virt-manager --debug:
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (cli:187) Launched with 
command line: /usr/share/virt-manager/virt-manager --debug
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (virt-manager:150) 
virt-manager version: 1.0.1
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (virt-manager:151) 
virtManager import: 
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (virt-manager:209) GTK 
version: 3.14.5
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (engine:484) libguestfs 
inspection support: False
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (systray:152) Showing 
systray: False
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (engine:231) About to 
connect to uris ['lxc:///', 'xen:///', 'qemu:///system']
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (manager:216) Showing 
manager
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (engine:385) window counter 
incremented to 1
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (connection:995) Scheduling 
background open thread for xen:///
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (connection:1012) 
Background 'open connection' thread is running
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (connection:1063) 
Background open thread complete, scheduling notify
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (connection:1068) Notifying 
open result
[Sat, 07 Feb 2015 17:07:27 virt-manager 9708] DEBUG (error:84) error dialog 
message:
summary=Unable to connect to libvirt.

internal error: libxenlight state driver is not active

Verify that:
 - A Xen host kernel was booted
 - The Xen service has been started
details=Unable to connect to libvirt.

internal error: libxenlight state driver is not active

Verify that:
 - A Xen host kernel was booted
 - The Xen service has been started

Libvirt URI is: xen:///

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1020, in 
_open_thread
self._backend.open(self._do_creds_password)
  File "/usr/share/virt-manager/virtinst/connection.py", line 158, in open
open_flags)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 105, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: internal error: libxenlight state driver is not active
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
[Sat, 07 Feb 2015 17:07:29 virt-manager 9708] DEBUG (connection:995) Scheduling 
background open thread for qemu:///system
[Sat, 07 Feb 2015 17:07:29 virt-manager 9708] DEBUG (connection:1012) 
Background 'open connection' thread is running
[Sat, 07 Feb 2015 17:07:30 virt-manager 9708] DEBUG (connection:1063) 
Background open thread complete, scheduling notify
[Sat, 07 Feb 2015 17:07:30 virt-manager 9708] DEBUG (connection:1068) Notifying 
open result
[Sat, 07 Feb 2015 17:07:30 virt-manager 9708] DEBUG (connection:1074) libvirt 
version=1002009
[Sat, 07 Feb 2015 17:07:30 virt-manager 9708] DEBUG (connection:1076) daemon 
version=1002009
[Sat, 07 Feb 2015 17:07:30 virt-manager 9708] DEBUG (connection:1077) conn 
version=2001002
[Sat, 07 Feb 2015 17:07:30 virt-manager 9708] DEBUG (connection:1079) 
qemu:///system capabilities:


  
a0fe4482-3fb8-dc11-bb92-e03f49a06ed4

  x86_64
  Opteron_G5
  AMD
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  


  
  
tcp
rdma
  


  

  12230576
  3057644
  0
  

Bug#777348: systemd-sysv: 'shutdown -rf now' doesn't work

[Török Edwin]

Package: systemd-sysv
Version: 215-10
Severity: normal

Dear Maintainer,

* What led up to the situation?

  Upgrade a test VM from Debian wheezy to jessie

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

 'shutdown -rf now' command doesn't work anymore.

* What was the outcome of this action?

root@debianwheezy:~# shutdown -rf now
Code should not be reached 'Unhandled option' at 
../src/systemctl/systemctl.c:6316, function shutdown_parse_argv(). Aborting.
Aborted

* What outcome did you expect instead?

Either:
 * rebooting the system like it used to for wheezy
 * an error message that tells me that the '-f' flag is no (longer) supported

I did not expect to see an internal error in shutdown when called with wrong 
arguments.

FWIW if I use a truly unknown option I get a better error message:
# shutdown -z
shutdown: invalid option -- 'z'


* Workaround: use 'shutdown -r now' instead

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

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

Versions of packages systemd-sysv depends on:
ii  systemd  215-10

systemd-sysv recommends no packages.

systemd-sysv 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#777559: [aufs-tools] auplink crashes

[Török Edwin]

Package: aufs-tools
Version: 1:3.2+20130722-1.1
Severity: normal

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

Using a standard Debian kernel I noticed these crashes in dmesg:

[Mon Feb  9 18:27:58 2015] docker0: port 1(vethd6af4f5) entered forwarding state
[Mon Feb  9 18:27:58 2015] docker0: port 1(vethd6af4f5) entered forwarding state
[Mon Feb  9 18:28:13 2015] docker0: port 1(vethd6af4f5) entered forwarding state
[Mon Feb  9 18:30:17 2015] auplink[26764]: segfault at 7fffd11217f8 ip 
0031eb6db479 sp 7fffd1121800 error 6 in libc-2.19.so[31eb60+19f000]
[Mon Feb  9 18:30:17 2015] docker0: port 1(vethd6af4f5) entered disabled state
[Mon Feb  9 18:30:17 2015] device vethd6af4f5 left promiscuous mode
[Mon Feb  9 18:30:17 2015] docker0: port 1(vethd6af4f5) entered disabled state
[Mon Feb  9 18:30:17 2015] aufs au_plink_put:454:docker[9960]: pseudo-link is 
not flushed
[Mon Feb  9 18:30:32 2015] device vethb483b2f entered promiscuous mode
[Mon Feb  9 18:30:32 2015] IPv6: ADDRCONF(NETDEV_UP): vethb483b2f: link is not 
ready
[Mon Feb  9 18:30:32 2015] IPv6: ADDRCONF(NETDEV_CHANGE): vethb483b2f: link 
becomes ready
[Mon Feb  9 18:30:32 2015] docker0: port 1(vethb483b2f) entered forwarding state
[Mon Feb  9 18:30:32 2015] docker0: port 1(vethb483b2f) entered forwarding state
[Mon Feb  9 18:30:48 2015] docker0: port 1(vethb483b2f) entered forwarding state
[Mon Feb  9 18:42:32 2015] auplink[28259]: segfault at 7fff86fb8078 ip 
0031eb6db479 sp 7fff86fb8080 error 6 in libc-2.19.so[31eb60+19f000]
[Mon Feb  9 18:42:32 2015] aufs au_plink_put:454:docker[2727]: pseudo-link is 
not flushed
[Mon Feb  9 18:42:32 2015] docker0: port 1(vethb483b2f) entered disabled state
[Mon Feb  9 18:42:32 2015] device vethb483b2f left promiscuous mode
[Mon Feb  9 18:42:32 2015] docker0: port 1(vethb483b2f) entered disabled state
[Mon Feb  9 19:12:38 2015] device vethe4f62d0 entered promiscuous mode

$ uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 
GNU/Linux

Similar crashes reported here with some more info:
https://github.com/docker/docker/issues/10595

The testcase from that report reproduces the issue for me:
# auplink / flush
auplink:plink.c:341: no aufs mount point
Segmentation fault

# gdb auplink
(gdb) r / flush
Starting program: /sbin/auplink / flush
/sbin/auplink:plink.c:341: no aufs mount point

Program received signal SIGSEGV, Segmentation fault.
__strncpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy-ssse3.S:43
43  ../sysdeps/x86_64/multiarch/strcpy-ssse3.S: No such file or directory.
(gdb) bt
#0  __strncpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy-ssse3.S:43
#1  0x0040178c in strncpy (__len=20, __src=0x0, __dest=0x7fffe4f0 
"") at /usr/include/x86_64-linux-gnu/bits/string3.h:120
#2  au_plink (cwd=cwd@entry=0x604010 "/", cmd=cmd@entry=0, flags=flags@entry=1, 
fd=fd@entry=0x0) at plink.c:342
#3  0x004013ae in main (argc=, argv=) at 
auplink.c:64

I don't know why docker would call auplink on something that is not an aufs 
mountpoint (race condition?), but the crash when called on / reproduces 
everytime.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.0
  500 testing-updates ftp.ro.debian.org 
  500 testing security.debian.org 
  500 testing ftp.ro.debian.org 
  100 jessie-backports ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#777608: zenity: depends on libwebkitgtk which doesn't have security support

[Török Edwin]

Package: zenity
Version: 3.14.0-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

 Install debian-security-support package and try to remove the packages
 that don't have security support.

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

$ check-support-status
* Source:webkitgtk
  Details: No security support upstream and backports not feasible, only for
  use on trusted content
  Affected binary packages:
- libjavascriptcoregtk-3.0-0:amd64 (installed version: 2.4.8-1)
- libwebkitgtk-3.0-0:amd64 (installed version: 2.4.8-1)
- libwebkitgtk-3.0-common (installed version: 2.4.8-1)
# apt-get purge libwebkitgtk-3.0-0

   * What was the outcome of this action?

   The following packages will be REMOVED:
 libwebkitgtk-3.0-0* marco* mate-desktop-environment*
 mate-desktop-environment-core* mate-media* mate-media-pulse*
 task-mate-desktop* zenity*
 The following NEW packages will be installed:
   mate-media-gstreamer

   * What outcome did you expect instead?

   The desktop environment to stay installed.
   MATE, Cinnamon (and Gnome too) depend on zenity, which depends on 
libwebkitgtk-3.0-0.

   FWIW KDE depends on kdelibs4, where check-security-support complains about
   khtml. I haven't checked XFCE and LXDE.

   I see that zenity has a configure flag to enable/disable webkit support,
   would it be possible to provide a zenity-nohtml package that would
   "Provides: zenity" so I can keep my *DE installed without depending on a 
package that has
   no security support?
   (Or have a zenity-html and zenity-nohtml package both providing the virtual
   zenity package, and using recommends somehow to choose the html version by
   default?)


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

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

Versions of packages zenity depends on:
ii  libc6   2.19-13
ii  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.1-1
ii  libgtk-3-0  3.14.5-1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.36.8-3
ii  libwebkitgtk-3.0-0  2.4.8-1
ii  libx11-62:1.6.2-3
ii  zenity-common   3.14.0-1

zenity recommends no packages.

zenity 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#776850: RFP: sx -- Scalable public and private cloud storage

[Török Edwin]

Package: wnpp
Severity: wishlist

* Package name: sx
  Version : 1.0
  Upstream Author : Skylable Dev Team 
* URL : http://www.skylable.com/products/sx
* License : GPL-2 with OpenSSL exception
  Programming Lang: C
  Description : Scalable public and private cloud storage

 Skylable Sx is a reliable, fully distributed cluster solution for your data
 storage needs.
 .
 With Sx you can aggregate the disk space available on multiple servers and
 merge it into a single storage system.
 The cluster makes sure that your data is always replicated over multiple nodes
 (the exact number of copies is defined by the sysadmin) and synchronized.
 .
 Additionally Sx has built-in support for deduplication, client-side
 encryption, on-the-fly compression and much more.


I am part of the upstream developers, and we would welcome if a DD (team) would
submit and maintain this package in Debian.
We are interested in helping with the packaging and applying bugfixes upstream.

Preliminary packaging available at https://github.com/gcsideal/sx-debian/pull/1:
$ git clone https://github.com/edwintorok/sx-debian && cd sx-debian && git 
checkout pristine-tar && git checkout debian
$ git-buildpackage -us -uc -j8


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

Bug#775398: [libqt5widgets5] QSystemTrayicon doesn't work with MATE desktop

[Török Edwin]

Package: libqt5widgets5
Version: 5.3.2+dfsg-4+b1
Severity: normal

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

Steps to reproduce:
# apt-get install task-mate-desktop
# apt-get install qtbase5-examples
.. login to MATE desktop ...
$ /usr/lib/x86_64-linux-gnu/qt5/examples/widgets/desktop/systray/systray

Actual results:
No icon is shown in tray

Expected results:
Heart icon is shown in tray

This is a regression from Qt4:
# apt-get install qt4-demos
$ /usr/lib/qt4/examples/desktop/systray/systray

The Heart icon is shown in the tray correctly

Upstream bugreport: https://bugreports.qt.io/browse/QTBUG-43859

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.18.0-trunk-amd64

Debian Release: 8.0
  500 testing-updates ftp.ro.debian.org 
  500 testing vol-repo.s3.indian.skylable.com 
  500 testing security.debian.org 
  500 testing ftp.ro.debian.org 
  500 stable  vol-repo.s3.indian.skylable.com 
  100 jessie-backports ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#775591: [src:linux] AUFS missing from 3.18.0 kernel => Docker 10x slower

[Török Edwin]

Package: src:linux
Version: 3.18-1~exp1
Severity: normal

--- Please enter the report below this line. ---
Using linux-image-3.18.0-trunk-amd64 I noticed that AUFS is missing from 
/proc/filesystems.
This causes Docker to slow down even 10x in some situations: 
https://github.com/docker/docker/issues/10161
Please consider enabling AUFS again.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.0
  500 testing-updates ftp.ro.debian.org 
  500 testing vol-repo.s3.indian.skylable.com 
  500 testing security.debian.org 
  500 testing ftp.ro.debian.org 
  500 stable  vol-repo.s3.indian.skylable.com 
  100 jessie-backports ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#775591: [docker.io] overlayfs support

[Török Edwin]

Package: docker.io
Version: 1.3.3~dfsg1-2

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

The version of docker.io currently in Debian is too old to support overlayfs, 
however
the latest version (1.4.1) does support it:
"aufs",
"btrfs",
"devicemapper",
"vfs",
// experimental, has to be enabled manually for now
"overlay",

Performance still isn't as good as AUFS, but that might be due to using a 
different method to
diff in docker itself: 
https://github.com/docker/docker/issues/10161#issuecomment-70391211

For Debian stretch to avoid performance regressions compared to jessie:
 - overlay driver should be used instead of aufs driver (DOCKEROPTS=-s overlay 
for now until upstream changes the order)
 - improve overlay driver performance in docker, hopefully upstream will take 
care of this, see the referenced upstream bugreport

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.18.0-trunk-amd64

Debian Release: 8.0
  500 testing-updates ftp.ro.debian.org 
  500 testing vol-repo.s3.indian.skylable.com 
  500 testing security.debian.org 
  500 testing ftp.ro.debian.org 
  500 stable  vol-repo.s3.indian.skylable.com 
  100 jessie-backports ftp.ro.debian.org 
1 experimentalftp.ro.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


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

Bug#781332: adb: device offline (adb version too old?)

[Török Edwin]

Package: android-tools-adb
Version: 4.2.2+git20130529-5.1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Plug in Galaxy Tab 3.0 7" (SM-T210) with official ROM (Android 4.4.2) to USB
port.
USB debugging is enabled, and USB is in MTP mode.

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

$ adb version
Android Debug Bridge version 1.0.31
$ adb devices

   * What was the outcome of this action?

* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
5200d5605a095100offline

   * What outcome did you expect instead?
Using upstream Android SDK:
$ adb kill-server
$ ~/Android/Sdk/platform-tools/adb version
Android Debug Bridge version 1.0.32
$ ~/Android/Sdk/platform-tools/adb devices
List of devices attached
5200d5605a095100unauthorized

After accepting the popup on the device:
$ ~/Android/Sdk/platform-tools/adb devices
List of devices attached
5200d5605a095100device



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

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

Versions of packages android-tools-adb depends on:
ii  libc62.19-15
ii  libssl1.0.0  1.0.1k-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

android-tools-adb recommends no packages.

android-tools-adb 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#778821: vim: SEGV in lua plugin

[Török Edwin]

Package: vim
Version: 2:7.4.488-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Run Vim (both console and gvim) and after some time got a crash:
Vim: Caught deadly signal SEGV
Vim: Finished.

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

I don't have an exact testcase, it seems to happen after vim was left idle
for some time and I start typing again.
Yesterday Vim crashed again after several months, so I enabled core dumps 
and today it crashed again.

   * What was the outcome of this action?

[ The coredump below was for gvim but yesterday plain vim crashed too, so it 
looks like a
bug in core vim, not the GUI part hence reporting it on the vim package ]

Core was generated by `gvim'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f71b0e653d7 in kill () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x7f71b0e653d7 in kill () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f71b5cb212f in mch_exit ()
#2  
#3  0x7f71b5be2ac8 in set_ref_in_item ()
#4  0x7f71b5d5b58d in ?? ()
#5  0x7f71b258cc3d in luaD_precall (L=L@entry=0x7f71b83cac80,
func=, nresults=0) at ldo.c:319
#6  0x7f71b258cf72 in luaD_call (L=L@entry=0x7f71b83cac80, func=, nResults=nResults@entry=0, allowyield=allowyield@entry=0) at ldo.c:401
#7  0x7f71b25890ab in lua_callk (L=0x7f71b83cac80, nargs=,
nresults=0, ctx=, k=) at lapi.c:905
#8  0x7f71b5bec243 in garbage_collect ()
#9  0x7f71b5d46671 in gui_wait_for_chars ()
#10 0x7f71b5d32cac in ui_inchar ()
#11 0x7f71b5c4217f in inchar ()
#12 0x7f71b5c4422e in ?? ()
#13 0x7f71b5c449f3 in vgetc ()
#14 0x7f71b5c44e59 in safe_vgetc ()
#15 0x7f71b5c93bbc in normal_cmd ()
#16 0x7f71b5d7877d in main_loop ()
#17 0x7f71b5bb8a51 in main ()

I have several vim plugins, but only one uses lua AFAICT (rgrep 'lua ' 
~/.vim/bundle): https://github.com/Shougo/neocomplete.vim
I have installed that plugin since October 2014 (I was using neocomplcache 
before, which doesn't use lua).

In my vimrc I have these neocomplete settings:
let g:neocomplete#enable_at_startup = 1
if !exists('g:neocomplete#force_omni_input_patterns')
let g:neocomplete#force_omni_input_patterns = {}
endif
let g:neocomplete#force_omni_input_patterns.ocaml = '[^. *\t]\.\w*\|\h\w*|#'

My full .vimrc and .vim directory is available at 
https://gist.github.com/edwintorok/d74a3dd0aa71a840b7d2

Here is the full backtrace as well:

[New LWP 28948]
[New LWP 28949]
[New LWP 28950]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `gvim'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f71b0e653d7 in kill () at ../sysdeps/unix/syscall-template.S:81

Thread 3 (Thread 0x7f71a516f700 (LWP 28950)):
#0  0x7f71b0f0d18d in poll () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7f71b4691ee4 in g_main_context_poll (priority=2147483647, n_fds=2, 
fds=0x7f71a00010c0, timeout=-1, context=0x7f71b8209fb0) at 
/tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:4076
poll_func = 0x7f71b46a1310 
#2  g_main_context_iterate (context=0x7f71b8209fb0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at 
/tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3776
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x7f71a00010c0
#3  0x7f71b4692272 in g_main_loop_run (loop=0x7f71b8209f40) at 
/tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3975
__FUNCTION__ = "g_main_loop_run"
#4  0x7f71afc1af76 in gdbus_shared_thread_func (user_data=0x7f71b8209f80) 
at /tmp/buildd/glib2.0-2.42.1/./gio/gdbusprivate.c:273
data = 0x7f71b8209f80
#5  0x7f71b46b8935 in g_thread_proxy (data=0x7f71b81a54a0) at 
/tmp/buildd/glib2.0-2.42.1/./glib/gthread.c:764
thread = 0x7f71b81a54a0
#6  0x7f71b1fa80a4 in start_thread (arg=0x7f71a516f700) at 
pthread_create.c:309
__res = 
pd = 0x7f71a516f700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {14012607664, 
5676593371248834010, 0, 140126356574304, 140126334978272, 14012607664, 
-5754468145790208550, -5754425575544080934}, mask_was_saved = 0}}, priv = {pad 
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#7  0x7f71b0f15ccd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

Thread 2 (Thread 0x7f71a705f700 (LWP 28949)):
#0  0x7f71b0f0ef33 in select () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7f71b17aa0bd in NotifierThreadProc (clientData=) at 
/tmp/buildd/tcl8.6-8.6.2+dfsg/unix/tclUnixNotfy.c:1216
tsdPtr = 0x0
  

Bug#779332: lldb: cannot run executables or attach to processes

[Török Edwin]

Package: lldb
Version: 1:3.5-25
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Tried all the ways I could think of to run or attach lldb to a process and none
worked.
According to this it should've worked: http://lldb.llvm.org/lldb-gdb.html

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

$ echo 'int main() { while (1) {}; return 0; }' >x.c && gcc -g x.c -o x.gcc &&
clang -g x.c -o x.clang
$ lldb ./x.gcc
$ lldb ./x.clang
$ ./x.clang&
$ ./x.gcc&
$ lldb -p `pidof x.clang`
$ lldb -p `pidof x.gcc`

   * What was the outcome of this action?

$ lldb ./x.gcc
error: './x.gcc' doesn't contain the architecture x86_64
(lldb) run
error: invalid target, create a target using the 'target create' command
(lldb) target create ./x.gcc
error: './x.gcc' doesn't contain the architecture x86_64
(lldb) ^D

$ lldb ./x.clang
error: './x.clang' doesn't contain the architecture x86_64
(lldb) run
error: invalid target, create a target using the 'target create' command
(lldb) target create ./x.clang
error: './x.clang' doesn't contain the architecture x86_64
(lldb) ^D

$ lldb -p `pidof x.gcc`
error: attach failed: '/tmp/x.gcc' doesn't contain any 'host' platform
architectures: x86_64, i386
(lldb) ^D
$ lldb -p `pidof x.clang`
error: attach failed: '/tmp/x.gcc' doesn't contain any 'host' platform
architectures: x86_64, i386
(lldb) ^D

   * What outcome did you expect instead?

I never tried lldb before on Debian, but gdb works and trying the equivalent
lldb http://lldb.llvm.org/lldb-gdb.html commands should work.
At least the very basic ones about running a process or attaching to a running
process.

As it is currently I cannot figure out how to use lldb on Debian.



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

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

Versions of packages lldb depends on:
ii  lldb-3.5  1:3.5-9

lldb recommends no packages.

lldb 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#779669: OpenSSL: consider completely disabling EXPORT cipher suites

[Török Edwin]

Package: libssl1.0.0
Version: 1.0.1k-1
Severity: normal

Dear Maintainer,

CVE-2015-0204 [1] happened because OpenSSL still had code supporting export
cipher suites.
LibreSSL has disabled the use of export cipher suites [2] and all the code
relating to use of export RSA [3]

Although I'd much rather replace OpenSSL with LibreSSL on my box, it is not
ready yet for Jessie or unstable even [4], so meantime
can you consider disabling the export suites in OpenSSL like LibreSSL did, and
like you've done for SSLv3?
Perhaps something to discuss with upstream to provide a flag for that, although
maybe the correct thing to do would be to remove that code from upstream as
well.

[1]
https://github.com/openssl/openssl/commit/ce325c60c74b0fa784f5872404b722e120e5cab0
[2] https://github.com/libressl-
portable/openbsd/commit/9e3c8206e0f32386e79956dfa4a26bbfdb3dd10d
[3] https://github.com/libressl-
portable/openbsd/commit/b0a3dc11e2f40da00441447a359ed16e8c578e44
[4] https://github.com/libressl-
portable/openbsd/commit/9e3c8206e0f32386e79956dfa4a26bbfdb3dd10d



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

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

Versions of packages libssl1.0.0 depends on:
ii  debconf [debconf-2.0]  1.5.55
ii  libc6  2.19-15
ii  multiarch-support  2.19-15

libssl1.0.0 recommends no packages.

libssl1.0.0 suggests no packages.

-- debconf information:
  libssl1.0.0/restart-services:
  libssl1.0.0/restart-failed:


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

Bug#779669: [Pkg-openssl-devel] Bug#779669: OpenSSL: consider completely disabling EXPORT cipher suites

[Török Edwin]

On 03/04/2015 07:10 AM, Kurt Roeckx wrote:
> On Tue, Mar 03, 2015 at 10:45:41PM +0200, Török Edwin wrote:
>> can you consider disabling the export suites in OpenSSL like LibreSSL did, 
>> and
>> like you've done for SSLv3?
> 
> I do want to remove the export ciphers from the DEFAULT cipher
> string in all released branches.  I have patches upstream to do
> that, and to completly remove support for export ciphers in
> master.

Nice!

> 
>> [2] https://github.com/libressl-
>> portable/openbsd/commit/9e3c8206e0f32386e79956dfa4a26bbfdb3dd10d
>> [4] https://github.com/libressl-
>> portable/openbsd/commit/9e3c8206e0f32386e79956dfa4a26bbfdb3dd10d
> 
> That's the same link.

Sorry, the other link was supposed to be this that removes the ephemeral RSA:
https://github.com/libressl-portable/openbsd/commit/b0a3dc11e2f40da00441447a359ed16e8c578e44

Best regards,
--Edwin


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

Bug#779669: [Pkg-openssl-devel] Bug#779669: OpenSSL: consider completely disabling EXPORT cipher suites

[Török Edwin]

On 03/04/2015 05:40 PM, Kurt Roeckx wrote:
> On Wed, Mar 04, 2015 at 10:16:31AM +0200, Török Edwin wrote:
>> On 03/04/2015 07:10 AM, Kurt Roeckx wrote:
>>> On Tue, Mar 03, 2015 at 10:45:41PM +0200, Török Edwin wrote:
>>>> can you consider disabling the export suites in OpenSSL like LibreSSL did, 
>>>> and
>>>> like you've done for SSLv3?
>>>
>>> I do want to remove the export ciphers from the DEFAULT cipher
>>> string in all released branches.  I have patches upstream to do
>>> that, and to completly remove support for export ciphers in
>>> master.
>>
>> Nice!
>>
>>>
>>>> [2] https://github.com/libressl-
>>>> portable/openbsd/commit/9e3c8206e0f32386e79956dfa4a26bbfdb3dd10d
>>>> [4] https://github.com/libressl-
>>>> portable/openbsd/commit/9e3c8206e0f32386e79956dfa4a26bbfdb3dd10d
>>>
>>> That's the same link.
>>
>> Sorry, the other link was supposed to be this that removes the ephemeral RSA:
>> https://github.com/libressl-portable/openbsd/commit/b0a3dc11e2f40da00441447a359ed16e8c578e44
> 
> That's still only 3 distinc URLs.

Looks like the LibreSSL ITP url was missing: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513

--Edwin


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

Bug#782127: units_cur: TypeError: cannot concatenate 'str' and 'NoneType' objects

[Török Edwin]

Package: units
Version: 2.11-1
Severity: normal

Dear Maintainer,

Try to run units_cur to update exchange rates, and I get an error:
# units_cur
/usr/bin/units_cur:53: RuntimeWarning: Argument  is not an unicode
object. Passing an encoded string will likely have unexpected results.
  ascii = unidecode(names[i])
Traceback (most recent call last):
  File "/usr/bin/units_cur", line 71, in 
values = ['1|' + x +' euro' for x in values]
TypeError: cannot concatenate 'str' and 'NoneType' objects

I tried applying the patch from #767864 / using latest git, but I still get the
same error:
Traceback (most recent call last):
  File "./units_cur2", line 71, in 
values = ['1|' + x +' euro' for x in values]
TypeError: cannot concatenate 'str' and 'NoneType' objects

Looking at the xml file that units_cur parses it looks like some currencies
have no exchange rate:

ARS
Argentina Peso



I tried applying a patch like this and it worked, but this means some
currencies will just disappear:
--- a/units_cur2
+++ b/units_cur2
@@ -38,7 +38,7 @@
   sys.exit(1)

 # print codes here
-
+currencies = [ x for x in currencies if x.find('code').text != None and
x.find('description').text != None and x.find('rate').text != None ]
 codes = [x.find('code').text for x in currencies]
 names = [x.find('description').text for x in currencies]
 values = [x.find('rate').text for x in currencies]



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

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

Versions of packages units depends on:
ii  libc6 2.19-17
ii  libreadline6  6.3-8+b3

Versions of packages units recommends:
pn  python:any  

units 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#801210: [duplicity] duplicity: should use more reliable locking (fcntl-based)

[Török Edwin]

Package: duplicity
Version: 0.7.03-1
Severity: normal

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

I noticed that duplicity isn't performing the daily backups that I scheduled 
from a cron job [1], instead it fails like this every day:

/etc/cron.daily/backup:

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Mon Jun  8 09:18:54 2015
No extraneous files found, nothing deleted in cleanup.
Another instance is already running with this archive directory
If you are sure that this is the  only instance running you may delete
the following lockfile and run the command again :
/var/cache/duplicity/96c9f57d3b62aef19b25e2cc03d2f0ab/lockfile.lock
run-parts: /etc/cron.daily/backup exited with return code 23

--- ---

Looks like duplicity can't deal with stale lock files that are left around
when rebooting while duplicity is still running.

Would you consider using POSIX advisory locks (fcntl F_SETLK) instead?
The locks are automatically released when the process exits or crashes, and you 
can even determine
which process is currently holding the lock (fcntl F_GETLK). 
There are some limitations if you open the file multiple times or use multiple 
threads [2],
but should be more reliable than relying just on the presence of a file.

[1] /etc/cron.daily/backup calls duplicity like this:
--- ---
for DIR in $BDIRS
do

  if [ "$DIR" = '.' ]; then
TARGETDIR=system
EXCLUDE="--exclude-filelist /root/duplicity-exclude.conf"
  else
TARGETDIR="$DIR"
EXCLUDE="--exclude-filelist /root/duplicity-exclude-$DIR.conf"
  fi

  export PASSPHRASE=
  export SIGN_PASSPHRASE=
  LOGFILE="$LOGDIR/`basename $TARGETDIR`.log"
  duplicity --volsize $VOLSIZE --archive-dir $ARCHIVEDIR remove-all-but-n-full 
2 --force -v3 "$TARGET/$TARGETDIR/" >>$LOGFILE
  duplicity cleanup --archive-dir $ARCHIVEDIR --force $TARGET/$TARGETDIR/

  duplicity --exclude-other-filesystems --full-if-older-than 1M --volsize 
$VOLSIZE --archive-dir $ARCHIVEDIR -v5 --encrypt-key $ENCRYPTKEY --sign-key 
$SIGNKEY $EXCLUDE /$DIR $TARGET/$TARGETDIR/ >>$LOGFILE 

done

[2] https://www.sqlite.org/howtocorrupt.html 'Posix advisory locks canceled by 
a separate thread doing close()'

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.1.0-0.bpo.2-amd64

Debian Release: 8.2
  900 stable  security.debian.org 
  900 stable  httpredir.debian.org 
  900 jessie-backports httpredir.debian.org 
  500 unstablehttpredir.debian.org 
  500 testing vol-repo.s3.indian.skylable.com 
  500 testing httpredir.debian.org 
  500 stable-updates  httpredir.debian.org 
1 experimentalhttpredir.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.