Bug#1071395: runit: as init breaks several cronjobs
Hi, This looks very good and should work for me. Many thanks! On Sun, Aug 25, 2024 at 6:57 AM Lorenzo wrote: > Dear Mo Jun, > > I propose the following: > > * drop /lib/lsb/init-functions.d/40-runit > > * add /etc/runit/override-sysv.d/default-runit > > default-runit will set the policy about forwarding the > invoke-rc.d action to runscripts. The default policy will > be the same as now, but it will be possible to override it > for each script, so for example (for anacron) > > - /etc/runit/override-sysv.d/anacron.block --> always block >invoke-rc.d for anacron > - /etc/runit/override-sysv.d/anacron.runit --> always forward to >the anacron runscript, even if it's already managed by >runit-helper or trigger_sv > - /etc/runit/override-sysv.d/anacron.sysv --> always call the >sysvinit script for anarcon > > this way we could limit the signal-twice thing to runscript that > need it; for example, the anacron runscript in runit-services package > will create the /etc/runit/override-sysv.d/anacron.runit file so that > cronjobs are not skipped. > > to summarize, the difference from the current status will be: > > * the main policy script will be below /etc/ so the user can modify > default-runit and all changes will be persistent on upgrade > > * default policy tunable for each service, by touching files inside > /etc/runit/override-sysv.d/ > will be very convenient to create or remove those files with the > runscript > > * the policy will work only for invoke-rc.d calls, direct call > to /etc/init.d/foo is out of scope. This will create issue with > the few packages that call the script without using invoke-rc.d, > but the number is manageble (I will file bugs) and I think it's not > correct forbid the local admin to run a script in the system if he > wants to.. > > let me if will work for you. > > Regards, > Lorenzo > >
Bug#1071395: runit: as init breaks several cronjobs
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
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
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
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
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. Version
Bug#1051056: transmission-daemon: memory leaks lead to eventual memory exhaustion
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
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, accel_blocked =
Bug#875911: libqsastime-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
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
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)
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
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, @@ -263,18 +258,6 @@
Bug#828625: nethack-console: wizard mode permanently identify does not works on armhf port
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
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", &iflags.use_hpmon, FALSE, SET_IN_GAME}, -#endif #ifdef OPT_DISPMAP { "fast_map", &flags.fast_map, TRUE, SET_IN_GAME }, #else @@ -131,6 +128,9 @@ { "help", &flags.help, TRUE, SET_IN_GAME }, { "hilite_pet", &iflags.wc_hilite_pet, FALSE, SET_IN_GAME }, /*WC*/ { "hilite_pile", &iflags.hilite_pile, FALSE, SET_IN_GAME }, +#if defined(TEXTCOLOR) && defined(HPMON) +{ "hpmon", &iflags.use_hpmon, FALSE, SET_IN_GAME}, +#endif #ifndef MAC { "ignintr", &flags.ignintr, FALSE, SET_IN_GAME }, #else
Bug#766028: [pkg-wine-party] Bug#766028: (no subject)
On 12/8/14, Michael Gilbert 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) 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
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