Bug#1071395: runit: as init breaks several cronjobs

[Mo Jun]

Followup-For: Bug #1071395
Package: runit

Hi,

On Mon, 20 May 2024 15:35:03 +0200 Lorenzo  wrote:
> thanks for your detailed report:
> the problem that you describe is real, but there is no easy/ catch-all
> solution. Keep in mind that a certain number of maintainers are removing
> cronjobs in favor of systemd timers

Thanks for your quick reply.
Please mind that this issue is not restrict to cronjobs; some packages
call invoke-rc.d/sysvinit scripts elsewhere, not restrict to cronjobs.
And yes, I have noticed some(many?) Maintainers are shifting to support
systemd-only things.

I have done searches using `sudo grep -rl "invoke-rc\.d"' and
`sudo grep -rl "/etc/init\.d/"' in /etc/ on my system running Debian sid.
After a quick look, here are scripts I found calling invoke-rc.d directly:
  /etc/cron.d/anacron
  /etc/dhcp/dhclient-exit-hooks.d/ntpsec
  /etc/init.d/selinux-autorelabel
  /etc/logrotate.d/apache2
  /etc/logrotate.d/cups-daemon
  /etc/logrotate.d/tor
  /etc/network/if-up.d/ntpsec-ntpdate
  /etc/ppp/ip-up.d/0stunnel4
  /etc/ppp/ip-down.d/0stunnel4

Here are those calling /etc/init.d/script directly:
  /etc/bash_completion.d/openvpn
  /etc/inittab
  /etc/logrotate.d/stunnel4
  /etc/network/if-down.d/openvpn
  /etc/network/if-up.d/mountnfs
  /etc/network/if-up.d/openvpn
  /etc/ppp/ip-up.d/usepeerdns
  /etc/ppp/ip-down.d/usepeerdns

There are many matches for `sudo grep -rl "/etc/init\.d/"' under
/etc/init.d/, but I do not have a look for all of them. And /etc/init.d/
is also mentioned in /etc/needrestart/hook.d/{10-dpkg,90-none} which are
perl scripts, as I do not know about perl, I can not figure out them
actually call /etc/init.d/script or not.

Most aforementioned scripts calling invoke-rc.d/sysvinit scripts directly
use standard start/stop/reload... actions. Exceptions include:
  /etc/bash_completion.d/openvpn calls /etc/init.d/openvpn without args.
  /etc/logrotate.d/stunnel4 calls `/etc/init.d/stunnel4 reopen-logs'
  /etc/inittab calls `/etc/init.d/powerfail now'
(although there is no /etc/init.d/powerfail on my system)

As shown in /lib/rsyslog/rsyslog-rotate, some packages may call
invoke-rc.d or /etc/init.d/script directly outside /etc, and it is even
possible that some packages call them in binary executables.
So I think it may be a little difficult to find all those packages.

> it breaks some cronjobs, hopefully not all. For some just using the
> initscript nonstandard action, like 'reopen-logs' or 'rotate', may work.
> I don't have any estimate, maybe 90% work, maybe 90% are broken..

For the "rotate" action of rsyslog, forward it to initscript will not
work, as it needs a pid file which is no available when running
runit service. And the "reopen-logs" action of stunnel4 also needs
a pid file. I think it needs to examine each initscript to find out
whether forwarding a nonstandard action will work or not, making
having an estimate a little difficult.

> > Maybe `invoke-rc.d script action' and `/etc/init.d/script action'
> > should be forwarded to the corresponding native runit service to fix
> > this bug.
>
> how many cases there are, apart from anacron? If it's only anacron, I
> think is better to fix the cronjob rather than signalling each service
> twice (see below)

I agree that the optimal is to fix the cronjob and other things by
changing them to call runit services.

> it rules out services that are integrated with runit-helper or with a
> trigger in runit, otherwise they will be signaled twice each upgrade

I am curious about that is there major problems if a service being
signaled twice on each upgrade? If no, I think it may be a good
compromise that if /etc/runit/lsb.runit.forward is set, standard
actions will be forwarded to runit services unconditionally even if
they are integrated with runit-helper or with a trigger in runit, as
being signaled twice on upgrade is better than doing nothing during
normal operations. Still nonstandard actions need special
treatments. Obviously it is left to the user/sysadmin to decide
whether set /etc/runit/lsb.runit.forward or not. As it needs
time/effort to fix all related packages, I wish have this compromise,
so that I can have a more functional system.

> This is possible,  but what if orphan-sysvinit-scripts is not installed?

I have not test yet, but it seems to me that if orphan-sysvinit-scripts
is not installed, rsyslog will not receive SIGHUP after logrotate.
The rsyslog package ships with /etc/logrotate.d/rsyslog, which calls
/lib/rsyslog/rsyslog-rotate.(orphan-sysvinit-scripts ships its own
version of this file and diverted the original file to
/usr/lib/rsyslog/rsyslog-rotate.real)
The original /lib/rsyslog/rsyslog-rotate will do nothing on
non-systemd systems:

#!/bin/sh


if [ -d /run/systemd/system ]; then
systemctl kill -s HUP rsyslog.service
fi

> After all in a runit-init system it's likely that one wants to use
> runit services, not sysvinit scripts..

Agreed. Now I think it is easier to make the lograte for 

Bug#1071395: runit: breaks the functions of some packages with runit as init

[Mo Jun]

Package: runit
Version: 2.1.2-59
Severity: normal

Dear Maintainer,

Some package call invoke-rc.d for theirs functions. For example, anacron
have
installed /etc/cron.d/anacron which uses `/usr/sbin/invoke-rc.d anacron
start'
on non-systemd systems. And on non-systemd systems, `invoke-rc.d script
action'
is translated to `/etc/init.d/script action'. For example:

$ sudo sh -x /usr/sbin/invoke-rc.d anacron start
# skipped many lines
+ /etc/init.d/anacron start
+ exit 0

Some package actually call `/etc/init.d/script action' directly. For
example,
stunnel4 have installed /etc/logrotate.d/stunnel4 which calls
`/etc/init.d/stunnel4 reopen-logs'. (Although there is no native runit
service
for stunnel4 in Debian currently.)

On systems using runit as init, due to /lib/lsb/init-functions.d/40-runit,
`/etc/init.d/script action' is a no-op by default if there is a
corresponding
native runit service. This will breaks the functions of those packages. For
example:

$ sudo sh -x /etc/init.d/anacron start
# skipped many lines
+ [ ! -e /etc/runit/lsb.runit.mask ]
+ [ -d /etc/sv/anacron ]
+ [ -d /usr/share/runit/sv.current/anacron ]
+ [ -h /etc/service/anacron ]
+ [ -z  ]
+ [ -e /usr/share/runit/meta/anacron/installed ]
+ [ -e /etc/sv/anacron/.meta/bin ]
+ [ -e /usr/share/runit/sv.current/anacron/.meta/bin ]
+ exit 0

Maybe `invoke-rc.d script action' and `/etc/init.d/script action' should be
forwarded to the corresponding native runit service to fix this bug.

By the way, it is mentioned in the header of
/lib/lsb/init-functions.d/40-runit
that if /etc/runit/lsb.runit.forward is set, `/etc/init.d/script action'
will be
forwarded to sv "if /etc/sv/ exists and is enabled". However I do
not see this is implemented in the current version of 40-runit.invoke-rc.d

And another note. The orphan-sysvinit-scripts package have installed
/lib/rsyslog/rsyslog-rotate which calls `invoke-rc.d rsyslog rotate' on
non-systemd
systems. As there is no such rotate action in sv, the rotate action will be
forwarded to /etc/init.d/rsyslog, but that will not work if the native runit
service of rsyslog is running. After looked into /etc/init.d/rsyslog, I
find that
`/etc/init.d/rsyslog rotate' is the same as `sv hup rsyslog' and `sv reload
rsyslog'.
Maybe assists from the Maintainer of the orphan-sysvinit-scripts package is
needed
to make the lograte for rsyslog functional in runit-init systems.

Regards,
Jun MO

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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages runit depends on:
ii  libc6   2.38-11
ii  runit-helper2.16.2
ii  sysuser-helper  1.3.9+really1.4.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-59

Versions of packages runit suggests:
ii  runit-services  0.7.2
pn  socklog 
pn  ucspi-unix  
ii  zsh 5.9-6+b1

-- Configuration Files:
/etc/runit/1 changed [not included]
/etc/runit/2 changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

Bug#1051056: transmission-daemon: memory leaks lead to eventual memory exhaustion

[Mo Jun]

Package: transmission-daemon
Followup-For: Bug #1051056

Hi Alex,

My laptop is running Debian sid and I am using transmission-daemon consistently
from long time ago. I didn't observed any memory leak from 4.0.1-1(see [1] if
you are interested) to the current version(4.0.5-2).

By the way, as mentioned in [2], I think this bug is a duplicate of #1015003.
And I think it is also a duplicate of LP: #1973084 [3]. See the Bug Description
of LP: #1973084 for a good summary. If this bug is indeed a duplicate, it would
have been already fixed in unstable, testing and stable, and it does not exist
in oldstable and all older release. Also please note the submitter apparently
uses the stable realse.

Note: I deliberately do not merge/close this bug, as I think it is better
leave it for the Maintainer or the Submitter.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015003#25
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051056#22
[3] https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1973084

Regards,
Jun MO

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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages transmission-daemon depends on:
ii  adduser  3.137
ii  init-system-helpers  1.66-0local2
ii  libc62.38-7
ii  libcurl4t64  8.7.1-5
ii  libdeflate0  1.20-1
ii  libevent-2.1-7t642.1.12-stable-8.1+b3
ii  libgcc-s114-20240429-1
ii  libminiupnpc17   2.2.6-1
ii  libnatpmp1t6420230423-1.2
ii  libssl3t64   3.2.1-3
ii  libstdc++6   14-20240429-1
ii  libsystemd0  255.5-1
ii  transmission-common  4.0.5-2

Versions of packages transmission-daemon recommends:
ii  transmission-cli  4.0.5-2

Versions of packages transmission-daemon suggests:
pn  transmission-remote-gtk | transgui | tremotesf  

-- Configuration Files:
/etc/default/transmission-daemon changed:
ENABLE_DAEMON=0
CONFIG_DIR="/var/lib/transmission-daemon/info"
OPTIONS="--config-dir $CONFIG_DIR"

/etc/transmission-daemon/settings.json [Errno 13] Permission denied:
'/etc/transmission-daemon/settings.json'

-- no debconf information

Bug#1070448: polkitd: prevent a confusing message during configure on non-systemd systems

[Mo Jun]

Package: polkitd
Version: 124-2
Severity: wishlist
Tags: patch

Dear Maintainer,

In polkitd.postinst, the following is executed on non-systemd systems to stop
polkitd:

start-stop-daemon --stop --oknodo --quiet --exec
/usr/libexec/polkitd || true

This /usr/libexec/polkitd file is not on my system, and it can not be found in
current *_debian_dists_sid_{main,contrib,non-free}_Contents-{all,amd64}.lz4.
This causes a message emitted during the configure of the polkitd package:

Setting up polkitd (124-2) ...
Creating group 'polkitd' with GID 994.
Creating user 'polkitd' (User for polkitd) with UID 994 and GID 994.
start-stop-daemon: unable to stat /usr/libexec/polkitd (No such file
or directory)

This message(start-stop-daemon: unable to ...) is useless and may confuse users.
I suggest change this line and the line before it as the following to prevent
this message:

test -x /usr/lib/polkit-1/polkitd && start-stop-daemon --stop
--oknodo --quiet --exec /usr/lib/polkit-1/polkitd || true
test -x /usr/libexec/polkitd && start-stop-daemon --stop
--oknodo --quiet --exec /usr/libexec/polkitd || true

A full patch is attached. Please consider apply this change or take any other
modification to prevent the possible confusing message from emitting.

Regards,
Jun MO

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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages polkitd depends on:
ii  adduser  3.137
ii  dbus [default-dbus-system-bus]   1.14.10-4+b1
ii  libc62.38-7
ii  libduktape2072.7.0-2+b1
ii  libexpat12.6.2-1
ii  libglib2.0-0t64  2.80.0-9
ii  libpam-elogind [logind]  255.5-1debian1
ii  libpam0g 1.5.3-7
ii  libpolkit-agent-1-0  124-2
ii  libpolkit-gobject-1-0124-2
ii  libsystemd0  255.5-1
ii  opensysusers [systemd-sysusers]  0.7.3-2
ii  xml-core 0.19

polkitd recommends no packages.

Versions of packages polkitd suggests:
pn  polkitd-pkla  

Versions of packages polkitd is related to:
ii  elogind 255.5-1debian1
ii  libpam-elogind  255.5-1debian1
pn  libpam-systemd  
pn  systemd 

-- no debconf information
--- /var/lib/dpkg/info/polkitd.postinst	2024-03-17 03:22:27.0 +0800
+++ /tmp/polkitd.postinst	2024-05-05 21:28:05.829634044 +0800
@@ -39,8 +39,8 @@
 # On non-systemd systems, polkitd is started as a traditional D-Bus
 # system service and is not managed by a service manager, so this is
 # the best we can do
-start-stop-daemon --stop --oknodo --quiet --exec /usr/lib/polkit-1/polkitd || true
-start-stop-daemon --stop --oknodo --quiet --exec /usr/libexec/polkitd || true
+test -x /usr/lib/polkit-1/polkitd && start-stop-daemon --stop --oknodo --quiet --exec /usr/lib/polkit-1/polkitd || true
+test -x /usr/libexec/polkitd && start-stop-daemon --stop --oknodo --quiet --exec /usr/libexec/polkitd || true
 fi
 }
 

Bug#924132: runit: Add support for runit in init-system-helpers

[Mo Jun]

Package: init-system-helpers
Version: 1.66
Followup-For: Bug #924132

Dear Maintainer,

Kindly ask if is there any progress of this bug. It will be very grateful for
adding support of runit in init-system-helpers as it will make use runit as
system init a bit easier.

I just start to use runit, so please correct me if I am wrong. Honestly it
seems to me that runit's support for sysvinit is poor, making use runit as
system init hard. Yes, runit-init will start scripts under /etc/rc2.d/ for me
as done in /etc/runit/2 during boot. But after boot completes, sv status/up/down
is not working for scripts under /etc/init.d/. Maybe it is better to solve this
by improving support for sysvinit in runit. But if this can be easily done in
init-system-helpers, it may still be a choice. And doing this in
init-system-helpers
has a benefit that have a consistent interface between different init. When I
used systemd as init, I still was used to use `service start/stop' to manage
system daemons. It will be thankful to still use that when use runit as init.

So really please consider adding support for runit in this package.

Regarding to the merge requests by Lorenzo Puliti[1], I have applied it into
and rebuild the init-system-helpers package. It helps me immediately. Although
maybe more polish(or update) is still needed. The first one is that the patch
only consider service under /etc/sv/. Under /etc/service/, I see there are
symlinks to not only /etc/sv/*, but also /usr/share/runit/sv.current/*.
/usr/share/runit/sv.current/* is provided by the runit-services
package and may also
be treated. Another one is `service --status-all' now only shows runit services.
It will better to show both runit services and sysvinit services. This
may be done
by the following changes:

--- a/script/service
+++ b/script/service
@@ -79,6 +87,26 @@
   functions | halt | killall | single| linuxconf| kudzu)
   ;;
   *)
+if [ -n "$is_runit" ]; then
+   runit_service=
+   if [ -d "/etc/sv/${SERVICE}" ]; then
+ runit_service="/etc/sv/${SERVICE}"
+   elif [ -d "/usr/share/runit/sv.current/${SERVICE}" ]; then
+ runit_service="/usr/share/runit/sv.current/${SERVICE}"
+   fi
+
+   if [ -n "$runit_service" ]; then
+ sv status "$runit_service" \
+   | sed -e 's|run: /etc/sv/| \[ + ] run: |' \
+ -e 's|down: /etc/sv/| \[ - ] down: |' \
+ -e 's|fail: /etc/sv/|disabled: |' \
+ -e 's|run: /usr/share/runit/sv.current/|
\[ + ] run: |' \
+ -e 's|down:
/usr/share/runit/sv.current/| \[ - ] down: |' \
+ -e 's|fail:
/usr/share/runit/sv.current/|disabled: |'
+ continue
+   fi
+fi
+
 if ! is_ignored_file "${SERVICE}" \
 && [ -x "${SERVICEDIR}/${SERVICE}" ]; then
 out=$(env -i LANG="$LANG"
LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC"
LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY"
LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME"
LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE"
LC_MEASUREMENT="$LC_MEASUREMENT"
LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH"
TERM="$TERM" "$SERVICEDIR/$SERVICE" status 2>&1)

instead of the original changes:

--- a/script/service
+++ b/script/service
@@ -73,6 +80,11 @@ while [ $# -gt 0 ]; do
;;
 *)
if [ -z "${SERVICE}" -a $# -eq 1 -a "${1}" = "--status-all" ]; then
+  if [ -n "$is_runit" ]; then
+ exec sv status /etc/sv/* \
+ | sed -e 's|run: /etc/sv/|\[ + ] run: |' -e 's|down:
/etc/sv/|\[ - ] down: |' -e 's|fail: /etc/sv/|disabled: |'
+ exit 0
+  fi
   cd ${SERVICEDIR}
   for SERVICE in * ; do
 case "${SERVICE}" in

I attach the debdiff between my build against 1.66 if it will help.

[1]: https://salsa.debian.org/debian/init-system-helpers/merge_requests/10

Regards,
Jun Mo

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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages init-system-helpers depends on:
ii  runit-helper  2.16.2
ii  usr-is-merged 39
ii  usrmerge [usr-is-merged]  39

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Bug#1051056: transmission-daemon: memory leaks lead to eventual memory exhaustion

[Mo Jun]

Package: transmission-daemon
Followup-For: Bug #1051056

Hi Rob,

I think this bug is a duplicate of #1015003 which is reported by me. Your
valgrind log and analysis are very similar to mine.

#1015003 was introduced by debian/patches/openssl3-compat.patch, and for
stable(bookworm) it was fixed in 3.00-2.1+deb12u1 by dropping
openssl3-compat.patch and using a simpler patch from Gentoo[1].

I see your transmission-daemon is at 3.00-2.1+b1, upgrade to
3.00-2.1+deb12u1 should fix it.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015003#84

Bug#884829: xserver-xorg-video-nouveau: memory leak in Xorg when audacious is playing with Info Bar Visualization

[Mo Jun]

On 12/22/17, Sven Joachim  wrote:

> I am reassigning it to the xserver-xorg-core package.  Hopefully
> somebody who knows more about X than I do can give further help.

Thanks Joachim for reassigning this bug.

And I am providing further informations and a walk around.

I probably have found exactly where the memory blocks are loss.
The postion is after FreePixmap() at pixmap.c:133.

This can be verified using Valgrind and GDB.
A detailed log is attached as xorg-vgdb.txt. Below is explanation.
I have rebuilt the xorg-server package with
DEB_CFLAGS_MAINT_APPEND="-O0 -g3" before running the test.

 (gdb) target remote | vgdb
 (gdb) b pixmap.c:132
 (gdb) c
 (gdb) n
133 in ../../../../dix/pixmap.c

Then run leak_check to set increment count of valgrind to zero:

 (gdb) monitor leak_check summary reachable
 (gdb) c

Then hit at pixmap.c:132 again:

Thread 1 hit Breakpoint 1, FreePixmap (pPixmap=0x13cb2170)
at ../../../../dix/pixmap.c:132
132 in ../../../../dix/pixmap.c
 (gdb) monitor leak_check reachable
==13478== 224 (+224) bytes in 1 (+1) blocks are still reachable in
loss record 2,567 of 3,164
==13478==at 0x4C2ABEF: malloc (vg_replace_malloc.c:299)
==13478==by 0x5E5FABA: pixman_rect_alloc (pixman-region.c:465)
==13478==by 0x5E60F8B: pixman_op (pixman-region.c:828)
==13478==by 0x5E62858: pixman_region_subtract (pixman-region.c:1987)
==13478==by 0xAC09408: RegionSubtract (regionstr.h:271)
==13478==by 0xAC097F5: exaCopyDirty (exa_migration_classic.c:128)
==13478==by 0xAC09EDE: exaCopyDirtyToFb (exa_migration_classic.c:303)
==13478==by 0xAC0C948: exaDoMigration_mixed (exa_migration_mixed.c:118)
==13478==by 0xAC08536: exaDoMigration (exa.c:1132)
==13478==by 0xAC0E928: exaHWCopyNtoN (exa_accel.c:468)
==13478==by 0xAC0EED8: exaCopyNtoN (exa_accel.c:581)
==13478==by 0x32A84B: miCopyRegion (micopy.c:121)
==13478==by 0x32ADB2: miDoCopy (micopy.c:296)
==13478==by 0xAC0F01B: exaCopyArea (exa_accel.c:608)
==13478==by 0x2A32E5: damageCopyArea (damage.c:775)
==13478==by 0x15A757: ProcCopyArea (dispatch.c:1722)
==13478==by 0x156F48: Dispatch (dispatch.c:479)
==13478==by 0x166152: dix_main (main.c:287)
==13478==by 0x146B91: main (stubmain.c:34)
==13478==
==13478== 26,200 (+200) bytes in 131 (+1) blocks are still reachable
in loss record 3,126 of 3,164
==13478==at 0x4C2ABEF: malloc (vg_replace_malloc.c:299)
==13478==by 0x1899A5: AllocatePixmap (pixmap.c:119)
==13478==by 0xB451823: fbCreatePixmapBpp (fbpixmap.c:53)
==13478==by 0xB4519F3: fbCreatePixmap (fbpixmap.c:97)
==13478==by 0xAC0B97D: exaCreatePixmap_mixed (exa_mixed.c:63)
==13478==by 0x159A7F: ProcCreatePixmap (dispatch.c:1441)
==13478==by 0x156F48: Dispatch (dispatch.c:479)
==13478==by 0x166152: dix_main (main.c:287)
==13478==by 0x146B91: main (stubmain.c:34)
==13478==
==13478== LEAK SUMMARY:
==13478==definitely lost: 119,574 (+0) bytes in 585 (+0) blocks
==13478==indirectly lost: 2,591 (+0) bytes in 38 (+0) blocks
==13478==  possibly lost: 23,658 (+0) bytes in 193 (+0) blocks
==13478==still reachable: 14,784,670 (+424) bytes in 21,242 (+2) blocks
==13478== suppressed: 0 (+0) bytes in 0 (+0) blocks
==13478==

There is no memory loss, but 2 new reachable memory blocks.
What related to my issue is the one alloc'd by malloc() which is
called by pixman_rect_alloc():

 (gdb) monitor block_list 2567
==13478== 224 (+224) bytes in 1 (+1) blocks are still reachable in
loss record 2,567 of 3,164
==13478==at 0x4C2ABEF: malloc (vg_replace_malloc.c:299)
==13478==by 0x5E5FABA: pixman_rect_alloc (pixman-region.c:465)
### backtrace removed for clarify ###
==13478== 0x13CC2CC0[224]

0x13CC2CC0[224] is only referenced by *0x13cb2218:

 (gdb) monitor who_points_at 0x13cc2cc0
==13478== Searching for pointers to 0x13cc2cc0
==13478== *0x13cb2218 points at 0x13cc2cc0
 Address 0x13cb2218 is 168 bytes inside a block of size 200 alloc'd
==13478==at 0x4C2ABEF: malloc (vg_replace_malloc.c:299)
==13478==by 0x1899A5: AllocatePixmap (pixmap.c:119)
==13478==by 0xB451823: fbCreatePixmapBpp (fbpixmap.c:53)
==13478==by 0xB4519F3: fbCreatePixmap (fbpixmap.c:97)
==13478==by 0xAC0B97D: exaCreatePixmap_mixed (exa_mixed.c:63)
==13478==by 0x159A7F: ProcCreatePixmap (dispatch.c:1441)
==13478==by 0x156F48: Dispatch (dispatch.c:479)
==13478==by 0x166152: dix_main (main.c:287)
==13478==by 0x146B91: main (stubmain.c:34)

0x13cb2218 is related to pPixmap->devPrivates:
(the offset 0x18 is found by testing on pExaPixmap in exaDestroyPixmap_mixed();
its value may not fixed on 0x18)

 (gdb) p &(((ExaPixmapPrivPtr) (((void *)
pPixmap->devPrivates)+0x18))->validSys.data)
$3 = (pixman_region16_data_t **) 0x13cb2218

 (gdb) p *((ExaPixmapPrivPtr) (((void *) pPixmap->devPrivates)+0x18))
$1 = {area = 0x0, score = 0, use_gpu_copy = 1, sys_ptr = 0x0,
  sys_pitch = 440, fb_ptr = 0x0, fb_pitch = 448, fb_size = 0,
 

Bug#875911: libqsastime-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Mo Jun]

Package: libplplot-dev
Version: 5.13.0+dfsg-4
Followup-For: Bug #875911

Dear Maintainer,

It seems that this problem also exists in libplplot-dev package.

Upgrading the libplplot-dev package from 5.10.0+dfsg2-0.4+b3 to
5.13.0+dfsg-4 resulted in that '/usr/share/doc/libplplot12/examples' is
not deleted:

Preparing to unpack .../5-libplplot-dev_5.13.0+dfsg-4_amd64.deb ...
Unpacking libplplot-dev (5.13.0+dfsg-4) over (5.10.0+dfsg2-0.4+b3) ...
dpkg: warning: unable to delete old directory
'/usr/share/doc/libplplot12/examples': Directory not empty

and that '/usr/share/doc/libplplot-dev' is still a symlink:

$ ls -ld /usr/share/doc/libplplot-dev
lrwxrwxrwx 1 root root 11 Feb 17  2016 /usr/share/doc/libplplot-dev ->
libplplot12

and that 'changelog.Debian.gz', 'changelog.gz' and 'copyright' are missing in
/usr/share/doc/libplplot-dev:

$ ls -l /usr/share/doc/libplplot-dev/
total 4
drwxr-xr-x 2 root root 4096 Sep 26 12:32 examples

Regards,
Jun MO

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

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

Versions of packages libplplot-dev depends on:
ii  libfreetype6-dev2.8-0.2
ii  libltdl-dev [libltdl3-dev]  2.4.6-2
ii  libplplot15 5.13.0+dfsg-4
ii  libplplotcxx13  5.13.0+dfsg-4
ii  libplplotfortran0   5.13.0+dfsg-4
ii  libplplotqt25.13.0+dfsg-4
ii  libplplotwxwidgets1 5.13.0+dfsg-4
ii  libqhull-dev2015.2-2
ii  libqsastime-dev 5.13.0+dfsg-4
ii  libshp-dev  1.4.1-1

Versions of packages libplplot-dev recommends:
ii  cmake3.9.3-1
pn  libplplot-d  
ii  libplplot-lua5.13.0+dfsg-4
pn  libplplot-ocaml  
ii  pkg-config   0.29-4+b1

Versions of packages libplplot-dev suggests:
pn  plplot-doc  

-- debconf-show failed

Bug#857511: transmission-daemon: segfault in scrape_request_delegate() at announcer.c:1402

[Mo Jun]

Package: transmission-daemon
Version: 2.92-2
Severity: normal

Dear Maintainer,

1. These segfaults have happened 11 times on my system since Feb 26; the
  /var/log/syslog* have been rotated so that I can not check whether
  segfault has happened before Feb 26. These segfaults happened randomly.

   I have collected 6 cores of segfaults. Next description will use
  core.4 as example.

2. transmission-daemon started on 2017-03-11 09:29:27 using:
$ ulimit -c unlimited
$ > ~/tmp/transmission.log ; transmission-daemon --logfile
~/tmp/transmission.log --log-debug

Message in syslog related to core.4(the segfault on 08:11:32 have
no core file saved):

$ zgrep segfault /var/log/syslog.1
Mar 11 08:11:32 archon kernel: [  408.155176] transmission-da[2572]:
segfault at 0 ip 7f2850fe4a0c sp 7f284bfaeaf8 error 4 in
libc-2.24.so[7f2850e9c000+195000]
Mar 11 09:34:01 archon kernel: [ 5356.546761] transmission-da[14443]:
segfault at 0 ip 7f6df7849a0c sp 7f6df2813af8 error 4 in
libc-2.24.so[7f6df7701000+195000]

   The attachment is the gdb backtrace generated with following command:

$ gdb --batch -ex "bt" -ex "bt full" -ex "thread apply all bt full"
-ex "quit" transmission-daemon core.4 &> core.4.backtrace-log

3. Here are some investigation by myself.

   The request 0x7f6decb08fc0 used by scrape_request_delegate():

(gdb) p *((const tr_scrape_request *) 0x7f6decb08fc0)
$1 = {url = 0x0,
  log_name = "[FILENAME_OF_TORRENT_REMOVED---http://354.354.354.354:75535];,
'\000' , info_hash = {
"{INFO_HASH_REMOVED_1",
"INFO_HASH_REMOVED_2",
"INFO_HASH_REMOVED_3",
'\000'  }, info_hash_count = 3}

   Note that some text is changed due to private reason.
   Obviously, segfault happens because of request->url is NULL(0x0)
and is compared with "http"
  using memcmp()(announcer.c:1402).

   The request 0x7f6decb08fc0 is the 2nd element of local variable
  requests(0x7f6decb08a30) of function multiscrape():

(gdb) p &((const tr_scrape_request *) 0x7f6decb08a30)[1]
$4 = (const tr_scrape_request *) 0x7f6decb08fc0

   The request 0x7f6decb08fc0 is likely build from tr_tier
(tr_ptrArray *) 0x7f6df2813b60)->items[1] as the hash, name and
tracker are matched:

(gdb) p (((tr_tier *) ((tr_ptrArray *)
0x7f6df2813b60)->items[1])->tor->info->hash)
$11 = "{INFO_HASH_REMOVED_1"
(gdb) p (((tr_tier *) ((tr_ptrArray *)
0x7f6df2813b60)->items[1])->tor->info->name)
$13 = 0x7f6dec3fb110 "FILENAME_OF_TORRENT_REMOVED"
(gdb) p *(((tr_tier *) ((tr_ptrArray *)
0x7f6df2813b60)->items[1])->currentTracker)
$14 = {key = 0x7f6dec4f5ba0 "http://354.354.354.354:75535;,
  announce = 0x7f6dec4f5ae0 "http://354.354.354.354:75535/annonuce;,
  scrape = 0x0, tracker_id_str = 0x0, seederCount = -1, leecherCount = -1,
  downloadCount = -1, downloaderCount = 0, consecutiveFailures = 0, id = 59}

The torrent of this tr_tier:

(gdb) p *(((tr_tier *) ((tr_ptrArray *) 0x7f6df2813b60)->items[1])->tor)
$15 = {session = 0x560e62f8a920, info = {totalSize = 176553400,
originalName = 0x7f6dec3fb150 "FILENAME_OF_TORRENT_REMOVED",
name = 0x7f6dec3fb110 "FILENAME_OF_TORRENT_REMOVED",
torrent = 0x7f6dec46f990
"/home/kralcyor/.config/transmission-daemon/torrents/FILENAME_OF_TORRENT_REMOVED.7b8d920ba22ab7a5.torrent",
webseeds = 0x0, comment = 0x7f6dec32f450 "",
creator = 0x7f6dec3fb190 "rin-pr/0.5.1", files = 0x7f6dec2b2700,
pieces = 0x7f6dec468c90, trackers = 0x7f6dec46e0e0,
dateCreated = 1485837788, trackerCount = 68, webseedCount = 0,
fileCount = 1, pieceSize = 262144, pieceCount = 674,
hash = "{INFO_HASH_REMOVED_1",
hashString = "HASH_STRING_REMOVED_1",
isPrivate = false, isFolder = false}, magicNumber = 95549,
  error = TR_STAT_OK, errorString = '\000' ,
  errorTracker = '\000' ,
  obfuscatedHash = "OBFUSCATED_HASH_REMOVED_1",
  incompleteMetadata = 0x0, peer_id = "-TR2920-k0igydl6wtr0",
  peer_id_creation_time = 1489195834,
  downloadDir = 0x7f6dec45df80 "DOWNLOAD_DIR_REMOVED",
  incompleteDir = 0x0, infoDictLength = 13587, infoDictOffset = 0,
  currentDir = 0x7f6dec45df80 "DOWNLOAD_DIR_REMOVED",
  blockSize = 16384, blockCount = 10776, lastBlockSize = 15800,
  lastPieceSize = 130488, blockCountInPiece = 16, blockCountInLastPiece = 8,
  completion = {tor = 0x7f6dec46fa10, blockBitfield = {bits = 0x0,
  alloc_count = 0, bit_count = 10776, true_count = 10776,
  have_all_hint = true, have_none_hint = false},
sizeWhenDoneLazy = 176553400, sizeWhenDoneIsDirty = true,
haveValidLazy = 0, haveValidIsDirty = true, sizeNow = 176553400},
  completeness = TR_SEED, tiers = 0x7f6dec46f490, dhtAnnounceAt = 1489197288,
  dhtAnnounce6At = 1489197384, dhtAnnounceInProgress = false,
  dhtAnnounce6InProgress = false, lpdAnnounceAt = 1489195767,
  downloadedCur = 0, downloadedPrev = 180364824, uploadedCur = 0,
  uploadedPrev = 1582164452, corruptCur = 0, corruptPrev = 0,
  etaDLSpeedCalculatedAt = 0, etaDLSpeed_Bps = 0, etaULSpeedCalculatedAt = 0,
  etaULSpeed_Bps = 0, addedDate = 1485844188, activityDate = 

Bug#832652: Acknowledgement (scamp: queried reference catalogs of some types may have wrong sky zones)

[Mo Jun]

Sorry for the noise.

Now I think it is better to change the condition when "%2b" should be
added to whether dec
is large or equal to 0, i.e.
wcspos[lat] >= 0 ? "%2b" : "",
in case dec is exactly equals to 0.

By the way, I think there is a small mistake in the Description line
of aclient.patch.
It said wget replace aclient_cgi call; curl actually do the job.

Regards,
Jun MO

Bug#832652: scamp: queried reference catalogs of some types may have wrong sky zones

[Mo Jun]

Package: scamp
Version: 2.0.4-2+b1
Severity: normal
Tags: patch

Dear Maintainer,

1. how to reproduce this bug
  a) Find a FITS file and rename it to img.fits .
 I use a image [1] of M31 from NED in this demonstration.

  b) Run SExtractor:
   $ sextractor -d > default.sex
   $ echo -e "XWIN_IMAGE\nYWIN_IMAGE\nERRAWIN_IMAGE\nERRBWIN_IMAGE" >
scamp.param
   $ echo -e "ERRTHETAWIN_IMAGE\nFLUX_AUTO\nFLUXERR_AUTO\nFLAGS" >> scamp.param
   $ echo -e "FLAGS_WEIGHT\nFLUX_RADIUS" >> scamp.param
   $ cp /usr/share/sextractor/default.conv .
   $ sextractor -c default.sex -CATALOG_NAME img.cat \
 -PARAMETERS_NAME scamp.param -CATALOG_TYPE FITS_LDAC img.fits

  c) Run SCAMP:
   $ scamp -d > scamp.conf
   $ scamp -c scamp.conf -ASTREF_CATALOG GSC-2.3 -SAVE_REFCATALOG Y \
 -CHECKPLOT_DEV NULL -WRITE_XML N img.cat
 SCAMP can be killed when it has downloaded a reference catalog and start
   astrometric matching.

  d) Use ldactoasc to view the reference catalog:
   $ ldactoasc GSC-2.3*.cat
The ra is from 168.25 to 168.70, and the dec is from -0.25 to 0.25, while
  the expected ra should be about 10.5 and the expected dec should be about 41.

2. which types of reference catalogs are affected
   A quick test shows GSC-2.2, GSC-2.3, NOMAD-1.0, PPMX, UCAC-2, USNO-A1.0,
 USNO-A2.0 are affected. The queried catalogs of these types are all centered
 on (ra~168.5, dec~0), expect for PPMX which is centered on (ra=0, dec=0).

   Catalogs of 2MASS, CMC-14, GSC-1.3, TYCHO-2 don't have this problem.

   Other catalogs like SDSS-R*, UCAC-3, UCAC-4 can not be downloaded.

3. patch
   After apply the attached patch, catalogs of 2MASS, CMC-14, GSC-1.3, GSC-2.2,
 GSC-2.3, NOMAD-1.0, PPMX, SDSS-R8, SDSS-R9, TYCHO-2, UCAC-2, UCAC-3,
 UCAC-4, USNO-A1.0, USNO-A2.0, USNO-B1.0 can be downloaded and all have
 right sky zone.

   Other catalog can not be downloaded which may due to they do not cover M31.
 Though I did not examine it.

   In the attched patch, the comma "," between ra and dec in the cmdline for
 curl is removed, and "%2b"(URL encoding for "+") is added when dec is large
 than 0. When catalog servers process the URL, a string ra%2bdec will converted
 to ra+dec. This may be the reason why the patch works.

   Please consider further examining this bug.

Regards,
Jun MO

[1] 
https://ned.ipac.caltech.edu/img/1997UITVi.U..KC/MESSIER_031:I:V:c1997:ne.v3x300s.fits.gz

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

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

Versions of packages scamp depends on:
ii  curl  7.47.0-1
ii  libatlas3-base3.10.2-9+b1
ii  libc6 2.23-4
ii  libcsiro0 5.10.0+dfsg2-0.2
ii  libfftw3-single3  3.3.4-2+b1
ii  libltdl7  2.4.6-1
ii  libplplot12   5.10.0+dfsg2-0.2
ii  libqhull7 2015.2-1
ii  libqsastime0  5.10.0+dfsg2-0.2
ii  libshp2   1.3.0-8

scamp recommends no packages.

scamp suggests no packages.

-- debconf-show failed
diff -Nru scamp-2.0.4/debian/patches/aclient.patch scamp-2.0.4/debian/patches/aclient.patch
--- scamp-2.0.4/debian/patches/aclient.patch	2015-05-28 15:14:03.0 +0800
+++ scamp-2.0.4/debian/patches/aclient.patch	2016-07-28 11:56:09.0 +0800
@@ -57,7 +57,7 @@
  
  /* If these are not angular coordinates, file mode becomes mandatory */
if (lng == lat && refcat!=ASTREFCAT_FILE)
-@@ -223,13 +223,13 @@
+@@ -223,17 +223,17 @@
  
  /* Prepare mag limit section of the command line */
if (prefs.astref_maglim[0]>-99.0 || prefs.astref_maglim[1]<99.0)
@@ -70,8 +70,13 @@
  
 -  sprintf(cmdline, "%s %s%s %s -c %f12%+f12 -r %16g %s",
 -	prefs.cdsclient_path,
-+  sprintf(cmdline, "%s \"http://%s%s/viz-bin/aserver.cgi?%s&-c&%f,%f&-r&%g&%s\";,
++  sprintf(cmdline, "%s \"http://%s%s/viz-bin/aserver.cgi?%s&-c&%f%s%f&-r&%g&%s\";,
 +	"curl",
  	prefs.ref_server[0],
  	sport,
  	astrefcat[(int)refcat].cdsname,
+-	wcspos[lng], wcspos[lat],
++	wcspos[lng], wcspos[lat] > 0 ? "%2b" : "", wcspos[lat],
+ 	maxradius*DEG/ARCMIN,
+ 	maglimcmd);
+ 
Author: Ole Streicher 
Description: Replace aclient_cgi call by wget
 aclient_cgi is a script file that is distributed with cdsclient, which
 is not packaged for Debian.
--- a/configure.ac
+++ b/configure.ac
@@ -163,11 +163,6 @@
 [AS_HELP_STRING([--with-mkl-dir=],
 [Provide an alternative path to the MKL library])])
 
-# Provide a special option for CDSClient
-AC_ARG_WITH(cdsclient-dir,
-	[AS_HELP_STRING([--with-cdsclient-dir=],
-	[Alternative default to the aclient execution path])])
-
 # Provide a special option for the default XSLT URL
 with_xsl_url="file://"$(URBI_RESOLVE_DIR([$datadir]))"/$PACKAGE_NAME/$PACKAGE_NAME.xsl"
 AC_ARG_WITH(xsl_url,
@@ 

Bug#828625: nethack-console: wizard mode permanently identify does not works on armhf port

[Mo Jun]

Package: nethack-console
Version: 3.6.0-3
Severity: normal
Tags: patch

Dear Maintainer,

1. This bug is only found on armhf port; it is not found on amd64 port.
  It can be reproduced on a chroot Debian system on a ARMv7 smart phone
  and on a full Debian system in a QEMU virtual machine.

2. Method of reproduce and behavior of this bug
   1) Start a wizard mode game:
  $ sudo /usr/games/nethack-console -D
   2) Optional: Press ^W, then press Enter to wizard mode wish some random
 items; these created items are not fully identified.
   3) Press ^I, then the Debug Identify menu, which shows the character's
 inventory with all items temporarily identified, will appear.
   4) Press ^I again, then the Debug Identify menu disapeared, and
  a) the expected outcome: the game show
"You have already identified all of your possessions."
, if all items are already identified; or the game show full identify
information of items and those items will be permanently identified,
if there are some unidentified items in the inventory.
  b) the buggy outcome: nothing happen and unidentified items are still
unidentified.

3. Possible cause
  In the function display_pickinv(), a special menu item is added to the
  Debug Identify menu; the identifier of this item is set to
-1(src/invent.c:2083):
   any.a_char = -1;
  The type of any.a_char is char(include/wintype.h:16):
   char a_char;
  When ^I is pressed in the Debug Identify menu, the identifier will be
  returned by display_pickinv(). And wiz_identify() will check whether the
  return value of display_pickinv() equals -1(src/cmd.c:595):
   if (display_inventory((char *) 0, TRUE) == -1)
  then determine to fully identify all items or do nothing.

  However the type char is unsigned by default on arm port. "any.a_char = -1;"
  will set any.a_char to 255 actually on arm port(this can be verified
by using gdb), so
  that above if statement will never success, and the permanent wizard identify
  will never be performed.

  Since all involved codes are all in files under src/ and include/ dirs, it
  seems that this bug affects not only nethack-console, but also nethack-x11
  and nethack-lisp. As I did not test those two favors, this may not be true.

4. Demonstration patch
   After apply the attached patch, the bug disappeared.
   Please consider examine and apply it.

Regards,
Jun MO

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

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

Versions of packages nethack-console depends on:
ii  libc6   2.22-12
ii  libncurses5 6.0+20160319-2+b1
ii  libtinfo5   6.0+20160319-2+b1
ii  nethack-common  3.6.0-3

nethack-console recommends no packages.

nethack-console suggests no packages.

-- no debconf information
Description: fix permanently identify bug

The return value of display_inventory() is from a type char value; 
since the type char is unsigned on port arm by default, the if statement will 
never success and identify will not be commited.
--- a/src/cmd.c
+++ b/src/cmd.c
@@ -592,7 +592,7 @@
 {
 if (wizard) {
 iflags.override_ID = (int) cmd_from_func(wiz_identify);
-if (display_inventory((char *) 0, TRUE) == -1)
+if (display_inventory((char *) 0, TRUE) == (char) -1)
 identify_pack(0, FALSE);
 iflags.override_ID = 0;
 } else

Bug#818051: nethack-console: abnormal behavior of HP monitor

[Mo Jun]

Package: nethack-console
Version: 3.6.0-1
Severity: minor
Tags: patch

Dear Maintainer,

Two problems with HP monitor.

1. In a game with "hpmon" option enabled, if the bottom line look like below

  Dlvl:1  $:0  HP:14(16) Pw:2(2) AC:8  Exp:1

then "14(16)" should be green; further lower the HP, the color should turn
to yellow, then red and finally orange.

However in 3.6.0-1, in this case, the "(" in the "Pw:2(2)" have color and
change its color when HP changes. In some other case, the "(" may also lose
color; in some other case, the number between "Pw" and "(" may have color too.

I have recorded a case using script(1); if it is needed, I can send the
typescript file and timing file here.

After applied the attached patch and rebuilded the package, this
problem disappeared.

Possible cause: In 3.6.0 the gold symbol in the bottom line may be a encoded
glyph, so putmixed() is used to write the bottom line. But the code in the
HP monitor patch still use putstr() so that may cause the output incorrect.

2. In the options list displayed by the "O" command, "hpmon" option is
between "extmenu" and "fixinv". Since the option list is sorted, the correct
position of "hpmon" should be between "hilite_pile" and "ignintr".

The attached patch also contains a fix of this problem.

Regards,
Jun MO

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages nethack-console depends on:
ii  libc6   2.22-3
ii  libncurses5 6.0+20160213-1
ii  libtinfo5   6.0+20160213-1
ii  nethack-common  3.6.0-1

nethack-console recommends no packages.

nethack-console suggests no packages.

-- no debconf information
--- a/src/botl.c
+++ b/src/botl.c
@@ -100,7 +100,7 @@
 hp, hpmax, u.uen, u.uenmax, u.uac);
 #else
 curs(WIN_STATUS, 1, 1);
-putstr(WIN_STATUS, 0, newbot2);
+putmixed(WIN_STATUS, 0, newbot2);
 
 Sprintf(nb = eos(newbot2), "%d(%d)", hp, hpmax);
 #if defined(TEXTCOLOR) && !defined(LISP_GRAPHICS)
@@ -121,7 +121,7 @@
   if (hpcolor != NO_COLOR)
 term_start_color(hpcolor);
   if(hpattr!=ATR_NONE)term_start_attr(hpattr);
-  putstr(WIN_STATUS, hpattr, newbot2);
+  putmixed(WIN_STATUS, hpattr, newbot2);
   if(hpattr!=ATR_NONE)term_end_attr(hpattr);
   if (hpcolor != NO_COLOR)
 term_end_color();
--- a/src/options.c
+++ b/src/options.c
@@ -112,9 +112,6 @@
 #else
 { "extmenu", (boolean *) 0, FALSE, SET_IN_FILE },
 #endif
-#if defined(TEXTCOLOR) && defined(HPMON)
-{ "hpmon", _hpmon, FALSE, SET_IN_GAME},
-#endif
 #ifdef OPT_DISPMAP
 { "fast_map", _map, TRUE, SET_IN_GAME },
 #else
@@ -131,6 +128,9 @@
 { "help", , TRUE, SET_IN_GAME },
 { "hilite_pet", _hilite_pet, FALSE, SET_IN_GAME }, /*WC*/
 { "hilite_pile", _pile, FALSE, SET_IN_GAME },
+#if defined(TEXTCOLOR) && defined(HPMON)
+{ "hpmon", _hpmon, FALSE, SET_IN_GAME},
+#endif
 #ifndef MAC
 { "ignintr", , FALSE, SET_IN_GAME },
 #else

Bug#766028: [pkg-wine-party] Bug#766028: (no subject)

[Mo Jun]

On 12/8/14, Michael Gilbert mgilb...@debian.org wrote:
 If so, can you try nouveau instead?

After switch to nouveau, there is no segfault.

And I found a workaround:
Rebuild the wine source package with BINDNOW hardening flag disabled(patch
attached), then install the wine32 package, no segfault occurs with nvidia
proprietary driver.
diff -rupN old/wine-1.6.2/debian/changelog new/wine-1.6.2/debian/changelog
--- old/wine-1.6.2/debian/changelog	2014-12-01 06:23:28.0 +0800
+++ new/wine-1.6.2/debian/changelog	2014-12-08 12:00:09.624341306 +0800
@@ -1,3 +1,9 @@
+wine (1.6.2-17.1) UNRELEASED; urgency=medium
+
+  * Disable BINDNOW build hardening flags. Testing for #766028.
+
+ -- Roy Clark (kralcyor) royclark...@gmail.com  Mon, 08 Dec 2014 03:57:21 +
+
 wine (1.6.2-17) unstable; urgency=medium
 
   * Add libgl1-mesa-dri dependency to wine32 (closes: #766028).
diff -rupN old/wine-1.6.2/debian/rules new/wine-1.6.2/debian/rules
--- old/wine-1.6.2/debian/rules	2014-12-01 05:06:48.0 +0800
+++ new/wine-1.6.2/debian/rules	2014-12-08 12:00:28.980801236 +0800
@@ -3,7 +3,7 @@
 export DH_VERBOSE=1
 
 # unfortunately wine fails to build with pie enabled
-export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
+export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie,-bindnow
 
 VERSUFFIX=$(shell dpkg-parsechangelog | grep ^Source | cut -d\  -f2 | sed s/wine//g)
 

Bug#766028: wine32: SegFault when run a program require OpenGL/Direct3D

[Mo Jun]

Package: wine32
Version: 1.6.2-11
Severity: normal

Dear Maintainer,

Running a win32 program which require OpenGL/Direct3D using wine32
will cause segmentation fault happen. This program may be a game
require Direct3D, a testing OpenGL program which only display OpenGL
information, or dxdiag.exe which is a DirectX deagnostic tool
distributed in Debian libwine package.

As dxdiag.exe is common, I use it to discuss below.

With 1.6.2-8, 1.6.2-10 wine32, running below command will not cause
SegFault and GL version can got from wine debug messages:
   $ WINEDEBUG=+wgl wine32 dxdiag.exe 2 wine.log
   $ grep GL version wine.log
   trace:wgl:X11DRV_WineGL_InitOpenglInfo GL version :
3.3.0 NVIDIA 340.46.

With 1.6.2-11, 1.6.2-12 wine32, running the same command will cause SegFault:
   $ WINEDEBUG=+wgl wine32 dxdiag.exe 2 wine.log
   Segmentation fault
   $ cat wine.log
   Wine cannot find the ncurses library (libncurses.so.5).
   fixme:wbemprox:wbem_services_CreateInstanceEnum unsupported flags 0x0030
   fixme:wbemprox:enum_class_object_Next timeout not supported

Let core can be dumped when SegFault happen, then using gdb I found:
   $ gdb wine32 core
   ...
   Program terminated with signal SIGSEGV, Segmentation fault.
   #0  0x7de8ee0a in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
   (gdb)

/usr/lib/i386-linux-gnu/libGL.so.1 is finally soft link to
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.340.46 which is
provide by libgl1-nvidia-glx:i386 package.

Next I try strace and found something interesting. The same above
command will NOT cause SegFault even with 1.6.2-11, 1.6.2-12 wine32:
   $ WINEDEBUG=+wgl strace -f -o strace.log wine32 dxdiag.exe 2 wine.log
   $ grep GL version wine.log trace:wgl:X11DRV_WineGL_InitOpenglInfo
GL version : 3.3.0 NVIDIA 340.46.

It is something wrong with wine32? Though from changelog, it seems
like no change in i386 when upgrade from 1.6.2-10 to 1.6.2-11.

Some other information:
 change version of libwine have no effect on whether SegFault happen or not.
 wine64 1.6.2-12 will NOT cause SegFault. Other version of wine64 not tested.
 Lastest libgl1-nvidia-glx:i386 upgrade is earlier than wine32
upgrade, so I have not try different libgl1-nvidia-glx:i386 version.
Version of libgl1-nvidia-glx:i386 is 340.46-1, as it is not shown
below.
 My video card is GeForce G 105M/PCIe/SSE2.

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

Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wine32 depends on:
ii  libc6   2.19-11
ii  libwine 1.6.2-12
ii  libwine-gecko-2.21  2.21+dfsg2-1
ii  x11-utils   7.7+2

wine32 recommends no packages.

wine32 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