Bug#1057053: Blank video when playing AV1 encoded videos
Package: vlc Version: 3.0.20-0+deb12u1 When playing an AV1 encoded video from webm file, video display is blank and only audio is working. It seems to me that vlc tries hw acceleration via VDPAU although my card does not support AV1 hardware decoding. VLC should fall back to software decoding in this case. (It works properly if I disable hardware acceleration entirely in vlc) Please find command line output below: $ vlc Optimistic\ Delay.webm VLC media player 3.0.20 Vetinari (revision 3.0.20-0-g6f0d0ab126b) [5578b3e71520] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden. [7f3408004930] gl gl: Initialized libplacebo v4.208.0 (API v208) libva info: VA-API version 1.17.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_17 libva info: va_openDriver() returns 0 [7f34082550e0] gl gl: Initialized libplacebo v4.208.0 (API v208) [7f3404c1b580] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding [7f3404c1b580] main decoder error: buffer deadlock prevented $ vdpauinfo | grep AV1 AV1_MAIN --- not supported --- AV1_HIGH --- not supported --- AV1_PROFESSIONAL --- not supported --- Best regards, Andreas Messer -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature
Bug#1034833: sysv init script missing in tomcat10 package
Package: tomcat10
Version: 10.1.6-1
Dear maintainers, the tomcat10 package does not ship a sysvinit
script for use with traditional init. Please consider adding such
a script to the package since it will make things simpler for
users of sysvinit. I have attached a possible implementation of
such a script to this mail. (Derived from tomcat9 package with
some cleanup) I can offer to support/maintain this script
in future if desired.
Best regards,
Andreas Messer
--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
#!/bin/sh
### BEGIN INIT INFO
# Provides: tomcat10
# Required-Start:$local_fs $remote_fs $network
# Required-Stop: $local_fs $remote_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Tomcat 10
# Description: The Tomcat 10 servlet engine runs Java Web Archives.
### END INIT INFO
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC='Tomcat 10 servlet engine'
NAME=tomcat10
readonly DESC NAME
# exit cleanly if disabled or not installed
test -x /usr/libexec/tomcat10/tomcat-update-policy.sh || exit 0
test -x /usr/libexec/tomcat10/tomcat-start.sh || exit 0
test -x /usr/libexec/tomcat10/tomcat-locate-java.sh || exit 0
. /lib/init/vars.sh
test -t 0 && VERBOSE=yes
# set defaults for options
CATALINA_HOME=/usr/share/tomcat10
CATALINA_BASE=/var/lib/tomcat10
CATALINA_TMPDIR=/tmp/tomcat10-tmp
export CATALINA_HOME CATALINA_BASE CATALINA_TMPDIR
JAVA_OPTS=-Djava.awt.headless=true
JSP_COMPILER= # only used if nonempty
SECURITY_MANAGER=false
UMASK=022
export JAVA_HOME JAVA_OPTS JSP_COMPILER SECURITY_MANAGER UMASK
[ -r /etc/default/tomcat10 ] && . /etc/default/tomcat10
. /lib/lsb/init-functions
# somewhat LSB-compliant exit with failure
if test x"$1" = x"status"; then
exit_failure_msg() {
log_failure_msg "$@"
exit 4
}
else
exit_failure_msg() {
log_failure_msg "$@"
exit 1
}
fi
# figure out the JRE executable catalina.sh will use
# (we need it for start-stop-daemon --exec for reliability)
[ x"${JAVA_HOME}" = x ] && \
JAVA_HOME=$(su tomcat -s /bin/sh -c ".
/usr/libexec/tomcat10/tomcat-locate-java.sh; echo \${JAVA_HOME}")
[ x"${JAVA_HOME}" != x ] || exit_failure_msg "could not determine JRE"
JAVA="${JAVA_HOME}/bin/java"
[ -x "${JAVA}" ] || exit_failure_msg "could not find java executable ${JAVA}"
# prepare for actions
case $1 in
(start|stop|restart|force-reload)
# handled below
;;
(try-restart|status)
start-stop-daemon --status --quiet \
--pidfile /var/run/tomcat10.pid \
--exec "$JAVA" --user tomcat
rv=$?
# clean up stale pidfile if necessary
(test x"$rv" = x"1" && rm -f /var/run/tomcat10.pid || :)
# process status result
case $1 in
(try-restart)
test x"$rv" = x"0" || {
# service is not running, or status is unknown
log_success_msg "$NAME is not running"
exit 0
}
# service running, restart it
;;
(status)
case $rv in
(0)
log_success_msg "$NAME is running"
;;
(4)
log_failure_msg "could not access PID file for $NAME"
;;
(*)
log_failure_msg "$NAME is not running"
;;
esac
exit $rv
;;
esac
;;
(reload|*)
# not supported
echo >&2 "Usage: $0
{start|stop|restart|try-restart|force-reload|status}"
exit 3
;;
esac
# handle stopping/starting
rv=0
case $1 in
(stop|restart|try-restart|force-reload)
test x"$VERBOSE" = x"no" || log_daemon_msg "Stopping $DESC" "$NAME"
start-stop-daemon --stop --quiet \
--retry=10 --oknodo --remove-pidfile \
--pidfile /var/run/tomcat10.pid \
--exec "$JAVA" --user tomcat
rv=$?
test x"$VERBOSE" = x"no" || log_end_msg $rv
;;
esac
test x"$rv" = x"0" || exit $rv
case $1 in
(start|restart|try-restart|force-reload)
# ensure the temporary directory exist and change to it
rm -rf "$CATALINA_TMPDIR"
mkdir "$CATALINA_TMPDIR" || \
exit_failure_msg 'could not create JVM temporary directory'
chown -h tomcat "$CATALINA_TMPDIR"
cd "$CATALINA_TMPDIR"
# create log directory if not e
Bug#979044: Linphone unable to play shipped mkv ringtones
Package: linphone Version: 3.12.0-3 When configuring linphone to use one of its shipped .mkv ringtones, no sound is played and the following error message appears at the console: linphone-message : Starting local ringtone... linphone-error : No such filter with id 118 linphone-error : ring_start_with_cb(): could not create player for playing '/usr/share/sounds/linphone/rings/four_hands_together.mkv' The problem occurs since libmediastreamer-base10 is not built with libmatroska-c support. (special BelledonneCommunications version of libmatroska 2) There is no point in packaging the .mkv files if they can not be used. Please consider converting them to a supported format or removal from linphone-common package. Thanks! Cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature
Bug#972222: Unexpected dh_missing error when building for arch "all"
Package: debhelper Version: 13.2.1 When building a package and using option "--build=all", e.g. $ gbp buildpackage --build=all the build might fail with error message ... dh_install -p libvirt-daemon-system etc/libvirt/libxl.conf dh_install: warning: All requested packages have been excluded (e.g. via a Build-Profile or due to architecture restrictions). ... dh_missing: warning: etc/libvirt/libxl.conf exists in debian/tmp but is not installed to anywhere ... dh_missing: error: missing files, aborting I think the issues arises from Dh_getopt.pm, sub getoptions. I think it will immediately terminate the dh_* command when option "-p" is encountered and all packages are excluded. I suggest, this is wrong in case of dh_install because it prevents dh_install from logging the installed files tnd in the following make subsequent call to dh_missing fail. I found the problem when struggling with libvirt 6.7.0-2 source. With that package the build still failes, even after replacing override_dh_install-arch with override_dh_install in debian/rules cheers, Andreas Messer signature.asc Description: PGP signature
Bug#619454: Init script missing
Hello again, sorry, I'm stupid. This is not the same bug, will fill another ticket. > Hello, > I came across the same issue and found, that the the problem is > changed behavior of 'dh_installinit'. The file > > debian/lcdproc.init > > should be renamed to > > debian/lcdproc.LCDd.init > > according to the man-page when using the --name argument. > > Hope that helps, Regards, Andreas signature.asc Description: PGP signature
Bug#967058: Init script missing
Package: lcdproc Version: 0.5.9-4 The init script /etc/init.d/LCDd is missing. Hello, I think the problem is changed behavior of 'dh_installinit'. The file debian/lcdproc.init should be renamed to debian/lcdproc.LCDd.init according to the man-page when using the --name argument. Cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature
Bug#619454: Init script missing
Hello, I came across the same issue and found, that the the problem is changed behavior of 'dh_installinit'. The file debian/lcdproc.init should be renamed to debian/lcdproc.LCDd.init according to the man-page when using the --name argument. Hope that helps, Cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature
Bug#966083: libdpkg-perl: Unexpected termination when loading vendor
Package: libdpkg-perl
Version: 1.20.5
Severity: normal
Dear Maintainer,
when building tomcat9 package using gbp-buildpackage in an unstable
pbuilder/cowbuilder environment I got an unexpected exception when
dpkg-source tries to load an vendor. I'm on a Devuan System with
/etc/dpkg/origins/devuan which is also linked as 'default'. However my
does not have a file /usr/share/perl5/Dpkg/Vendor/Devuan.pm.
Having looked at the code, I think the intention was to load
the 'Parent' Vendor if no specific $vendor.pm file was found. In this
case /etc/dpkg/origins/devuan has content:
Vendor: Devuan
Vendor-URL: https://www.devuan.org/
Bugs: debbugs://bugs.devuan.org
Parent: Debian
I don't know why, but the exception within the 'eval' block seems not to
be caught and causes dpkg-source to exit with error code 127 but without any
message. Here is the stack trace of perl debugger:
DB<9> T
@ = DB::DB called from file '/usr/share/perl5/Dpkg/Exit.pm' line 82
$ = Dpkg::Exit::_exit_handler('Can\'t locate Dpkg/Vendor/Devuan.pm in @INC (you
may need to install the Dpkg::Vendor::Devuan module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30
/usr/share/perl/5.30 /usr/local/lib/site_perl) at (eval 36)[/usr/sha... called
from file '(eval 36)[/usr/share/perl5/Dpkg/Vendor.pm:164]' line 3
. = eval '
pop @INC if $INC[-1] eq \'.\';
require Dpkg::Vendor::Devuan;
$obj = Dpkg::Vendor::Devuan->new();
' called from file '/usr/share/perl5/Dpkg/Vendor.pm' line 164
$ = Dpkg::Vendor::get_vendor_object() called from file
'/usr/share/perl5/Dpkg/Vendor.pm' line 190
. = Dpkg::Vendor::run_vendor_hook('post-process-changelog-entry',
ref(Dpkg::Control::Changelog)) called from file
'/usr/share/perl5/Dpkg/Changelog.pm' line 548
@ = Dpkg::Changelog::_format_dpkg(ref(Dpkg::Changelog::Debian), ref(HASH))
called from file '/usr/share/perl5/Dpkg/Changelog.pm' line 653
@ = Dpkg::Changelog::format_range(ref(Dpkg::Changelog::Debian), 'dpkg',
ref(HASH)) called from file '/usr/share/perl5/Dpkg/Changelog/Parse.pm' line 141
$ = Dpkg::Changelog::Parse::changelog_parse('offset', 0, 'count', 1, 'file',
'tomcat9-9.0.37/debian/changelog') called from file
'/usr/share/perl5/Dpkg/Source/Package/V2.pm' line 616
@ =
Dpkg::Source::Package::V2::_get_patch_header(ref(Dpkg::Source::Package::V3::Quilt),
'tomcat9-9.0.37') called from file
'/usr/share/perl5/Dpkg/Source/Package/V2.pm' line 488
$ =
Dpkg::Source::Package::V2::_generate_patch(ref(Dpkg::Source::Package::V3::Quilt),
'tomcat9-9.0.37', 'order_from',
'tomcat9-9.0.37/debian/patches/debian-changes-9.0.37-1+devuan1', 'header_from',
'tomcat9-9.0.37/debian/patches/debian-changes-9.0.37-1+devuan1',
'handle_binary', ref(CODE), 'skip_auto', 0, 'usage', 'build') called from file
'/usr/share/perl5/Dpkg/Source/Package/V2.pm' line 558
. = Dpkg::Source::Package::V2::do_build(ref(Dpkg::Source::Package::V3::Quilt),
'tomcat9-9.0.37') called from file
'/usr/share/perl5/Dpkg/Source/Package/V3/Quilt.pm' line 217
. =
Dpkg::Source::Package::V3::Quilt::do_build(ref(Dpkg::Source::Package::V3::Quilt),
'tomcat9-9.0.37') called from file '/usr/share/perl5/Dpkg/Source/Package.pm'
line 606
. = Dpkg::Source::Package::build(ref(Dpkg::Source::Package::V3::Quilt),
'tomcat9-9.0.37') called from file '/usr/bin/dpkg-source' line 433
DB<9>
-- Package-specific info:
-- System Information:
Distributor ID: Debian
Description:Devuan GNU/Linux 3 (ceres)
Release:3
Codename: ceres
Architecture: x86_64
Kernel: Linux 5.4.8-amesser (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libdpkg-perl depends on:
ii dpkg 1.20.5
ii perl 5.30.3-4
--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
signature.asc
Description: PGP signature
Bug#941937: apt: Unexpected linkage dependency on libsystemd
Package: apt Version: 1.8.2 Severity: normal I observed a linkage dependency on libsystemd. This was unexpected for me since I wouldn't expect a package manager depend on it. A package manager should be as lean as possible. Having reviewed the code, the only function using libsystemd is used to talk on dbus to inhibit system shutdown. Something which will work for systemd only. Would it make sense to use dlopen() to dynamically load libsystemd when needed and avoid the hard dependency on libsystemd? If systemd is installed, libsystemd will be available anyways. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (/etc/apt/preferences.d/avoid-systemd present, but not submitted) -- -- (/etc/apt/sources.list present, but not submitted) -- -- (/etc/apt/sources.list.d/devuan.list present, but not submitted) -- -- System Information: Debian Release: 10.0 Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2019.1 ii gpgv2.2.12-1+deb10u1 ii libapt-pkg5.0 1.8.2 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4 ii libseccomp2 2.3.3-4 ii libstdc++6 8.3.0-6 Versions of packages apt recommends: ii ca-certificates 20190110 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.11-7 ii dpkg-dev1.19.7 ii gnupg 2.2.12-1+deb10u1 ii powermgmt-base 1.34 ii synaptic0.84.6 -- no debconf information -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
I have been reading on this bug for a while now. On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote: > Would it be any help at all of the "dbus client-ish" bits and the > "direct API-ish" bits of the two libraries were split up into two > separate libraries? i.e. would that allow the c/r/p replacement of one > of the two libraries (AIUI the API one is the more problematic) to be > pushed further up the dependency stack? > > (my impression is no, but I thought I'd ask) > > > The only way I have got all of these components to work together on an > > elogind > > systemd is to ensure everything uses libelogind0. > > Has anyone investigated late dynamic binding using a stub library which > merely determines which init is running and then dlopens the > appropriate libsystemd0 of libelogind0 library and forwards the calls > to it? > [...] While this would be a possible approach, this would also require that all applications currently linking with libsystemd need to link with something different, e.g liblogind. I think there was already some discussion about this general logind stuff a while ago. However, my personal feeling is, all the issues we have with packaging and dependencies now raise from a single source, namely that libsystemd integrates lots of - in my opinion completely - orthogonal functions in a single binary. E.g.: - Managing system init and services - Managing sessions - Managing temporary files - Managing devices ... This is the reason why libelogind has been massively stubbed to become api compatible and this is the reason why it is not possible to simply replace a function like "session management" with another solution. As of my thinking, the only proper solution here would be to kindly, well forcefully insist on systemd upstream to split their library by function and enforce them to link their own binaries properly with these libs. E.g. - libsystemd -> system init and services - libsystem-login -> sessino management - libsystem-udev -> ... Andreas signature.asc Description: PGP signature
Bug#878261: kaccounts-providers: Missing dependency on libkf5purpose-bin
Package: kaccounts-providers Version: 16.08.3-1 Severity: important Dear Maintainer, the package provides the Google, Twitter and Owncloud account providers for KDE. The Google and Twitter providers are unusable without the corresponding services which are contained in package libkf5purpose-bin. But this dependency is missing. I would expect at least a "recommends" of libkf5purpose-bin package. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kaccounts-providers depends on: ii kio 5.28.0-2 ii kpackagetool5 5.28.1-1 ii libc6 2.24-11+deb9u1 ii libkaccounts1 16.08.3-1 ii libkf5coreaddons5 5.28.0-2 ii libkf5declarative55.28.0-1 ii libkf5i18n5 5.28.0-2 ii libkf5kiocore55.28.0-2 ii libkf5package55.28.1-1 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5gui55.7.1+dfsg-3+b1 ii libqt5qml55.7.1-2+b2 ii libqt5xml55.7.1+dfsg-3+b1 ii libstdc++66.3.0-18 ii signon-plugin-oauth2 0.22-1 kaccounts-providers recommends no packages. kaccounts-providers suggests no packages. -- no debconf information
Bug#824207: ghostscript: Segmentation fault when printing in color mode
Package: ghostscript Version: 9.06~dfsg-2+deb8u1 Severity: normal Dear Maintainer, when trying to make a print using colors from any application (gimp, inkscape...) no printing happens. Ghostscript segfaults due to mutex issue in glibc. The problem is related to an already fixed bug in ghostscript's recursive mutex handling: http://bugs.ghostscript.com/show_bug.cgi?id=695862 The problem only occurs on Intel Skylake based machines supporting TSX memory like XEON cpus. (Supporting hardware accelerated mutexes) These mutexes are sensitive to wrong usage, e.g. double unlocking which actually happens in ghostscript due to the buggy implementation Here is a backtrace: Core was generated by `/usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -sDEVICE='. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fc4823de140 in __lll_unlock_elision () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) bt #0 0x7fc4823de140 in __lll_unlock_elision () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7fc48506c409 in gp_monitor_leave (mona=0x1fbece8) at ./base/gp_psync.c:197 #2 0x7fc48502571a in gsicc_get_link_profile (pis=, dev=, gs_input_profile=0x1fe2600, gs_output_profile=0x1fe2600, rendering_params=0x7ffe6ab60850, memory=, devicegraytok=1) at ./base/gsicc_cache.c:797 #3 0x7fc485025b8b in gsicc_get_link (pis=0x1e485d8, dev_in=0x20e1c58, pcs_in=0x1fbece8, pcs_in@entry=0x20f3860, output_colorspace=0x1, rendering_params=0x7ffe6ab60850, memory=0x0) at ./base/gsicc_cache.c:537 #4 0x7fc485020cf9 in gx_remap_ICC (pcc=0x20f2f30, pcs=0x20f3860, pdc=0x20f32e8, pis=0x1e485d8, dev=0x20e1c58, select=gs_color_select_texture) at ./base/gsicc.c:353 #5 0x7fc4851a1d4c in gx_remap_color (pgs=0x1e485d8) at ./base/gxcmap.c:558 #6 0x7fc48518efb8 in do_stroke (pgs=0x1e485d8) at ./base/gspaint.c:402 #7 gs_stroke (pgs=0x1e485d8) at ./base/gspaint.c:495 #8 0x7fc484f89b0a in interp (pi_ctx_p=0x1e4d518, pref=0x1e64730, perror_object=0x1fbece8, perror_object@entry=0x7ffe6ab61420) at ./psi/interp.c:1287 #9 0x7fc484f8a84b in gs_call_interp (perror_object=0x7ffe6ab61420, pexit_code=0x7ffe6ab6141c, user_errors=1, pref=0x7ffe6ab612a0, pi_ctx_p=) at ./psi/interp.c:501 #10 gs_interpret (pi_ctx_p=, pref=pref@entry=0x7ffe6ab613e0, user_errors=1, pexit_code=0x7ffe6ab6141c, perror_object=0x7ffe6ab61420) at ./psi/interp.c:459 #11 0x7fc484f7fcf8 in gs_main_interpret (perror_object=, pexit_code=, user_errors=, pref=0x7ffe6ab613e0, minst=) at ./psi/imain.c:241 #12 gs_main_run_string_end (minst=, user_errors=, pexit_code=, perror_object=) at ./psi/imain.c:607 #13 0x7fc484f81169 in run_string (minst=minst@entry=0x1e21770, str=str@entry=0x7fc4852036a0 ".runstdin", options=options@entry=2) at ./psi/imainarg.c:834 #14 0x7fc484f8181e in swproc (minst=minst@entry=0x1e21770, arg=0x7ffe6ab62c80 "", arg@entry=0x7ffe6ab62c7e "-_", pal=pal@entry=0x7ffe6ab61be0) at ./psi/imainarg.c:293 #15 0x7fc484f82770 in gs_main_init_with_args (minst=0x1e21770, argc=argc@entry=22, argv=argv@entry=0x7ffe6ab62708) at ./psi/imainarg.c:211 #16 0x7fc484f8363b in gsapi_init_with_args (lib=, argc=argc@entry=22, argv=argv@entry=0x7ffe6ab62708) at ./psi/iapi.c:174 #17 0x00400a0f in main (argc=22, argv=0x7ffe6ab62708) at ./psi/dxmainc.c:86 Updating to ghostscript package from stretch fixes the issue for me. -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.3-proton (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ghostscript depends on: ii debconf [debconf-2.0] 1.5.56 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.2 ii libc6 2.21-9 ii libgs9 9.06~dfsg-2+deb8u1 ghostscript recommends no packages. Versions of packages ghostscript suggests: ii ghostscript-x 9.06~dfsg-2+deb8u1 -- no debconf information
Bug#756316: iked failes to start
Hello,
the problem is caused by a bug in glibc package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810322
The problem can only reproduced on systems using TSX mutexes like Skylake
or Broadwell CPUs. Workaround:
diff -r -u ike-orig/source/libith/libith.cpp ike/source/libith/libith.cpp
--- ike-orig/source/libith/libith.cpp 2012-02-10 08:05:36.0 +0100
+++ ike/source/libith/libith.cpp2016-01-08 11:42:32.0 +0100
@@ -94,7 +94,7 @@
{
memset( obj_name, 0, 20 );
pthread_mutexattr_init( );
- pthread_mutexattr_settype( , PTHREAD_MUTEX_ERRORCHECK );
+ pthread_mutexattr_settype( , PTHREAD_MUTEX_NORMAL );
pthread_mutex_init( , );
}
Works for me without problems so far.
Andreas
signature.asc
Description: This is a digitally signed message part.
Bug#810322: libc6:amd64: Unexpected asseration in pthread_mutex_unlock()
Package: libc6
Version: 2.19-18+deb8u1
Severity: normal
Dear Maintainer,
when starting the iked from ike package the folloowing assertion occurs:
iked: pthread_mutex_unlock.c:87: __pthread_mutex_unlock_usercnt: Assertion
`type == PTHREAD_MUTEX_ERRORCHECK_NP' failed.
I have analyzed the problem and figured out that I can reproduce the problem
with
the following piece of code:
#include
#include
int main(int argc, char* argv[])
{
pthread_mutex_t mutex;
pthread_mutexattr_t attr;
struct timespec ts;
pthread_mutexattr_init( );
pthread_mutexattr_settype( , PTHREAD_MUTEX_ERRORCHECK );
pthread_mutex_init( , );
clock_gettime( CLOCK_REALTIME, );
ts.tv_sec += 3;
pthread_mutex_timedlock( , );
pthread_mutex_unlock();
return 0;
}
The problem does not occur with any other type of mutex.
Looking into the libc6 source code i figured out that the following happens:
1) pthread_mutex_timedlock() sets the PTHREAD_MUTEX_ELISION_NP flag through
FORCE_ELISION macro, which changes mutex->__data.__kind from 0x2 to 0x102
(pthread_mutex_timedlock.c:93)
2) pthread_mutex_unlock() asserts the mutex->__data.__kind
to be 0x2 (pthread_mutex_unlock.c:87)
In my opinion the assertation in pthread_mutex_unlock in line 87 is wrong.
It is:
assert (type == PTHREAD_MUTEX_ERRORCHECK_NP);
but should be:
assert (PTHREAD_MUTEX_TYPE(type) == PTHREAD_MUTEX_ERRORCHECK_NP);
as it is in the lines above also.
This problem also causes
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756316
As workaround, the mutex type PTHREAD_MUTEX_ERRORCHECK can be replaced by
PTHREAD_MUTEX_NORMAL in applications at the cost of less application
error checking.
-- System Information:
Debian Release: 8.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.3-proton (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libc6:amd64 depends on:
ii libgcc1 1:4.9.2-10
libc6:amd64 recommends no packages.
Versions of packages libc6:amd64 suggests:
ii debconf [debconf-2.0] 1.5.56
pn glibc-doc
ii locales2.19-18+deb8u1
-- debconf information excluded
Bug#780646: Workaround
Hi, I figured out that when removing the gtk2-engines-qtcurve packet the problem disappears. Regards, Andreas signature.asc Description: This is a digitally signed message part.
Bug#760142: systemd: Assertions from systemd-logind on powerpc during login, with continuing loop
Hi again, Am Sonntag, den 23.11.2014, 14:43 +0100 schrieb Andreas Messer: Am Samstag, den 22.11.2014, 10:20 + schrieb Simon McVittie: On Wed, 19 Nov 2014 at 21:29:33 +0100, Andreas Messer wrote: I'm observing the same behavior on an x86_64 wheezy system running my HTPC setup after updating the system some weeks ago. Andreas, I think your bug is #769069, which is a recent regression: your system is presumably much less slow than Chris's. The problem disappeared after downgrade to dbus 1.6.8-1+deb7u1 You don't want that version, it has a known buffer overrun. Please try upgrading to 1.6.8-1+deb7u4 again, then creating /etc/dbus-1/system-local.conf containing this: busconfig limit name=auth_timeout3/limit /busconfig That effectively reverts the problematic part of the changes from 1.6.8-1+deb7u4. Please let me know whether that makes it reliable for you. Thanks for the hint, I have done your suggestions and will report back in some days if the problem persists. Just to get back with some results: I did not observe the problem again in the last days, so the fix seems to solve the issue for me. Cheers, Andreas signature.asc Description: This is a digitally signed message part
Bug#760142: systemd: Assertions from systemd-logind on powerpc during login
Am Donnerstag, den 20.11.2014, 03:15 +0200 schrieb Andrei POPESCU: On Mi, 19 nov 14, 21:29:33, Andreas Messer wrote: Unfortunately I can only attach a cut from messages and daemon, I don't use the systemd journal. Unless you deliberately set Storage=none in /etc/systemd/journald.conf journald will have entries for the current boot (only). Please try if 'journalctl -alb' works for you and attach the output. My systemd does not understand -alb, only -a For some strange reason I dont get any output from that. But the files are there: root@vdr:/var/log/journal/5d3664a4a3fb1ee5f3e88f52525ac72f# ls -l insgesamt 2163540 -rw-r- 1 root adm 62566400 Sep 24 20:03 system@000503d37ebfac6d-393ee0e7c8639934.journal~ -rw-r- 1 root adm 84254720 Okt 9 20:03 system@3ee1307b9cd34bdfb2bdefa1b6809849-0001f090-000505013a8726d2.journal -rw-r- 1 root adm 66789376 Okt 17 20:10 system@3ee1307b9cd34bdfb2bdefa1b6809849-0003731b-000505a241f0dac8.journal -rw-r- 1 root adm532480 Okt 17 20:13 system@3ee1307b9cd34bdfb2bdefa1b6809849-00037538-000505a24cc9eaca.journal -rw-r- 1 root adm 132898816 Okt 31 18:16 system@3ee1307b9cd34bdfb2bdefa1b6809849-00067a06-000506bb297fe113.journal -rw-r- 1 root adm 12304384 Nov 2 20:06 system@3ee1307b9cd34bdfb2bdefa1b6809849-0006bb9e-000506e4e8e68ecb.journal -rw-r- 1 root adm765952 Nov 2 20:11 system@3ee1307b9cd34bdfb2bdefa1b6809849-0006bfb7-000506e4fa2406ef.journal -rw-r- 1 root adm 134217728 Apr 11 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-00289ef6-0004f6cb53468204.journal -rw-r- 1 root adm 134217728 Apr 20 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-002bd2f4-0004f77d8bdffee7.journal -rw-r- 1 root adm 134217728 Apr 27 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-002ef68e-0004f80b2ec6f1f0.journal -rw-r- 1 root adm 134217728 Mai 2 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-00320a15-0004f86f255dda2c.journal -rw-r- 1 root adm 134180864 Mai 4 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-00352589-0004f89795a63764.journal -rw-r- 1 root adm 134217728 Mai 7 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-0038462e-0004f8d300bf83d1.journal -rw-r- 1 root adm 134217728 Mai 8 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-003b6265-0004f8e6f5c26d1d.journal -rw-r- 1 root adm 134217728 Mai 10 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-003e7d58-0004f90c195430cd.journal -rw-r- 1 root adm 134217728 Mai 15 2014 system@a1c0dbe71e7e43e6846d95bf1556fb17-00416bed-0004f9744dadd7fc.journal -rw-r- 1 root adm 134217728 Jun 10 21:56 system@a1c0dbe71e7e43e6846d95bf1556fb17-00444a8d-0004fb80b78bc420.journal -rw-r- 1 root adm 134217728 Jul 18 00:22 system@a1c0dbe71e7e43e6846d95bf1556fb17-00472d0e-0004fe6b11eaf67b.journal -rw-r- 1 root adm 134217728 Aug 14 20:02 system@a1c0dbe71e7e43e6846d95bf1556fb17-004a1a98-0005009ab3939a10.journal -rw-r- 1 root adm 134217728 Sep 10 19:57 system@a1c0dbe71e7e43e6846d95bf1556fb17-004d079a-000502b9c965bcca.journal -rw-r- 1 root adm 109981696 Nov 23 14:32 system.journal -rw-r-+ 1 root adm 69632 Mai 11 2014 user-70003.journal root@vdr:/var/log/journal/5d3664a4a3fb1ee5f3e88f52525ac72f# systemd-journalctl -a Failed to iterate through journal: No such file or directory Sep 24 20:02:36 vdr systemd-journal[276]: Journal started I have no clue whats wrong, tried to remove the journal~ and the last journal file from Sep 10 but didnt help either. Cheers, Andreas signature.asc Description: This is a digitally signed message part
Bug#760142: systemd: Assertions from systemd-logind on powerpc during login, with continuing loop
Am Samstag, den 22.11.2014, 10:20 + schrieb Simon McVittie: On Wed, 19 Nov 2014 at 21:29:33 +0100, Andreas Messer wrote: I'm observing the same behavior on an x86_64 wheezy system running my HTPC setup after updating the system some weeks ago. Andreas, I think your bug is #769069, which is a recent regression: your system is presumably much less slow than Chris's. The problem disappeared after downgrade to dbus 1.6.8-1+deb7u1 You don't want that version, it has a known buffer overrun. Please try upgrading to 1.6.8-1+deb7u4 again, then creating /etc/dbus-1/system-local.conf containing this: busconfig limit name=auth_timeout3/limit /busconfig That effectively reverts the problematic part of the changes from 1.6.8-1+deb7u4. Please let me know whether that makes it reliable for you. Thanks for the hint, I have done your suggestions and will report back in some days if the problem persists. Cheers, Andreas signature.asc Description: This is a digitally signed message part
Bug#307354: ifupdown: terminates ppp interface before eth interface
Package: ifupdown Version: 0.6.4-4.12 Severity: normal I'm using /etc/network/interfaces to start my ppp connection (pppoe over eth0). At system boot everything works as expected. But at shutdown the eth0 interface is brought down before the ppp0 link. So pppd can not terminate correctly. This doesn't matter for usual configurations but I'm using some extra plugins with pppd which require pppd to exit cleanly. I think this problem can be solved by inserting following line to /etc/init.d/networking into the stop section before ifdown -a --exclude lo: ifdown -a --exclude eth --exclude lo I have not tested this yet but will do next days. Thanks, Andreas -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11-proton Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages ifupdown depends on: ii debconf [debconf-2.0] 1.4.30.11Debian configuration management sy ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii net-tools 1.60-10 The NET-3 networking toolkit -- debconf information: ifupdown/convert-interfaces: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
