Bug#928415: firefox-esr: All extensions are disabled
Hello, I found a workaround for firefox-esr 60.6.1esr-1~deb9u1 from Debian 9.9 Stretch/stable, and uBlock origin 1.18.16 from https://addons.mozilla.org (AMO). When uBlock origin was suddenly disabled today, I first changed this setting on the configuration page about:config : xpinstall.signatures.required = false This did not immediately solve the problem: I got the warning "proceed with care", but the extension was still disabled, and there was no way to enable it again. Then I also changed the settings: app.shield.optoutstudies.enabled = true app.normandy.run_interval_seconds = 5 The first option enables "studies", which are used to distribute the patch from Mozilla. On the Preferences page, the option "Allow Firefox to install and run studies" is now checked, although the user interface is still locked down. This setting also likes to disable itself on each restart. But if it is enabled on the page about:config, then it actually works until the next restart. The setting app.normandy.run_interval_seconds determines, how often "studies" are updated. The default value is 86400 seconds = 24 hours, which is far too long for testing. I set it to 5 seconds, waited that long and reloaded the Add-ons page. Surely I found a new extension "hotfix-update-xpi-intermediate 1.0.2". For some reason, uBlock origin was still disabled. I then toggled the setting xpinstall.signatures.required on and off, and reloaded the Add-ons page in-between. Then, at some point, uBlock origin was enabled again and working as before. So I think, that the setting xpinstall.signatures.required = false is not really needed. Enabling "studies" and using a short update interval of 5 seconds should do the trick. Regards, Hartmut Buhrmester
Bug#925455: alsa volume never saved/restored
Looking a bit further it seems that /var/lib/alsa/asound.state doesn't exist. That means that we are facing a chicken-egg problem here, the file will never be created as the service is never started (and then never stopped). I don't know, if it helps, but I could manually create a working settings file with: alsactl -f /var/lib/alsa/asound.state init alsactl -f /var/lib/alsa/asound.state store In the shell: root@debian:/var/lib/alsa# alsactl -f /var/lib/alsa/asound.state init Found hardware: "ICH" "Analog Devices AD1881A" "AC97a:41445348" "0x1043" "0x11d4" Hardware is initialized using a generic method root@debian:/var/lib/alsa# ls -l insgesamt 0 root@debian:/var/lib/alsa# alsactl -f /var/lib/alsa/asound.state store root@debian:/var/lib/alsa# ls -l insgesamt 8 -rw-r--r-- 1 root root 5680 Apr 7 18:55 asound.state root@debian:/var/lib/alsa# Since then, the sound level was properly saved and restored on restart. /var/log/syslog on start: Apr 7 19:41:46 debian systemd[1]: Starting Save/Restore Sound Card State... Apr 7 19:41:46 debian systemd[1]: Started Save/Restore Sound Card State. Apr 7 19:41:46 debian systemd[1]: Reached target Sound Card. /var/log/syslog on shutdown: Apr 7 19:45:17 debian systemd[1]: Stopped target Sound Card. Apr 7 19:45:17 debian systemd[1]: Stopping Save/Restore Sound Card State... I doesn't say "Stopped Save/Restore Sound Card State.", though. So the last confirmation seems to be missing. But it still works, as far as I can tell... I think, I always needed to run "alsactl init" at least once since Debian 8 Jessie, and this is still mentioned in the Debian Wiki: Configure alsa by running the command 'alsactl init' as root. Then reboot and try to test your sound. -- https://wiki.debian.org/ALSA Regards, Hartmut Buhrmester
Bug#873315: firefox-esr does not print typographic ligatures fi and fl
Furthermore, the missing ligatures are not replaced with some "weird character", but with an inverted question mark ¿ as used in Spanish. Thus, Zertifikat is displayed as Zerti¿kat (see attached screenshot replacement-character.png). Regards, Hartmut Buhrmester
Bug#873315: firefox-esr does not print typographic ligatures fi and fl
fi and fl are common typographic ligatures. They are the first ligatures shown in the Wikipedia article: https://en.wikipedia.org/wiki/Typographic_ligature https://en.wikipedia.org/wiki/Typographic_ligature#/media/File:Ligature_drawing.svg The Zertifikat becomes Zertifikat, and kostenpflichtig becomes kostenpflichtig. It depends on the fonts used by the web site and the available fonts on the Linux system, whether they can be displayed and printed correctly. It could also depends on other settings, e.g. composite characters could automatically be "decomposed". If in doubt, let the web site use its own fonts, e.g. do not disable the setting "Allow pages to choose their own fonts, instead of your selections above". Or try the "Noto" fonts - they are meant to prevent any missing characters. To learn more, install the package "unicode" and try: $ unicode "ligature fi" $ unicode "ligature fl" Regards, Hartmut Buhrmester
Bug#921418: Kernel update from 4.18 to 4.19 breaks vlc (update)
The latest kernel update for stretch-backports seems to solve the problems with vlc. This update was on Thu, Feb 14 2019. The logfile /var/log/aptitude says: Aptitude 0.8.7: log report Thu, Feb 14 2019 03:41:42 +0100 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 4 packages, and remove 0 packages. 151 MB of disk space will be used [HOLD, DEPENDENCIES] manpages-de:i386 2.9-1~bpo9+1 [INSTALL, DEPENDENCIES] apparmor:i386 2.11.0-3+deb9u2 [INSTALL, DEPENDENCIES] libapparmor-perl:i386 2.11.0-3+deb9u2 [INSTALL, DEPENDENCIES] linux-image-4.19.0-0.bpo.2-686-pae:i386 4.19.16-1~bpo9+1 [UPGRADE] linux-image-686-pae:i386 4.19+101~bpo9+1 -> 4.19+102~bpo9+1 Log complete. Then we may update the results table to: Kernel 4.9.130 4.18.20 4.19.124.19.16 -- --- --- ------ vlc-3.0.3 okay okay program_hangs okay vlc-3.0.6 okay okay program_hangs okay The tested kernels are: package-version kernel-version --- -- linux-image-4.9.0-8-686-pae 4.9.130-2 linux-image-4.18.0-0.bpo.3-686-pae 4.18.20-2~bpo9+1 linux-image-4.19.0-0.bpo.1-686-pae 4.19.12-1~bpo9+1 linux-image-4.19.0-0.bpo.2-686-pae 4.19.16-1~bpo9+1 These packages are referenced by a meta-package linux-image-686-pae, which still has a different numbering scheme. I don't know, what caused the problems with vlc, or what solved them in the end. I suspected at some point, that there might be changes to the "radeon" driver, but there are no obvious changes to "radeon" between kernel 4.19.12 and 4.19.16. So it might be a side effect of something completely different. I learned, that old package versions can be found at https://snapshot.debian.org/ , if others like to repeat these tests. Regards, Hartmut Buhrmester
Bug#921418: Kernel update from 4.18 to 4.19 breaks vlc
]
I also attached the output of:
~$ vlc -vv Arrival_Trailer_2016.mp4 2>&1 | tee -a vlc_$(date
+%Y-%m-%d_%H-%M-%S).txt
Regards,
Hartmut Buhrmester
[008ce110] main libvlc debug: VLC media player - 3.0.6 Vetinari
[008ce110] main libvlc debug: Copyright © 1996-2018 the VideoLAN team
[008ce110] main libvlc debug: revision 3.0.6-0-g5803e85f73
[008ce110] main libvlc debug: configured with ./configure
'--build=i686-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include'
'--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info'
'--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules'
'--libdir=${prefix}/lib/i386-linux-gnu'
'--libexecdir=${prefix}/lib/i386-linux-gnu' '--disable-maintainer-mode'
'--disable-dependency-tracking' '--config-cache' '--disable-update-check'
'--enable-fast-install' '--docdir=/usr/share/doc/vlc'
'--with-binary-version=3.0.6-0+deb9u1' '--enable-a52' '--enable-aa'
'--enable-bluray' '--enable-avahi' '--enable-caca' '--enable-chromaprint'
'--enable-chromecast' '--enable-dbus' '--enable-dca' '--enable-dvbpsi'
'--enable-dvdnav' '--enable-faad' '--enable-flac' '--enable-fluidsynth'
'--enable-freerdp' '--enable-freetype' '--enable-fribidi' '--enable-gles2'
'--enable-gnutls' '--enable-harfbuzz' '--enable-jack' '--enable-kate'
'--enable-libass' '--enable-libmpeg2' '--enable-libxml2' '--enable-lirc'
'--enable-live555' '--enable-mad' '--enable-matroska' '--enable-mod'
'--enable-mpc' '--enable-mpg123' '--enable-mtp' '--enable-ncurses'
'--enable-notify' '--enable-ogg' '--enable-opus' '--enable-pulse' '--enable-qt'
'--enable-realrtsp' '--enable-samplerate' '--enable-sdl-image' '--enable-sftp'
'--enable-shine' '--enable-shout' '--enable-skins2' '--enable-sndio'
'--enable-soxr' '--enable-speex' '--enable-svg' '--enable-svgdec'
'--enable-taglib' '--enable-theora' '--enable-twolame' '--enable-upnp'
'--enable-vdpau' '--enable-vnc' '--enable-vorbis' '--enable-x264'
'--enable-x265' '--enable-zvbi' '--with-kde-solid=/usr/share/solid/actions/'
'--disable-aribsub' '--disable-d3d11va' '--disable-decklink'
'--disable-directx' '--disable-dsm' '--disable-dxva2' '--disable-fdkaac'
'--disable-fluidlite' '--disable-goom' '--disable-gst-decode'
'--disable-libplacebo' '--disable-libtar' '--disable-macosx'
'--disable-macosx-avfoundation' '--disable-macosx-qtkit' '--disable-mfx'
'--disable-opencv' '--disable-projectm' '--disable-schroedinger'
'--disable-sparkle' '--disable-srt' '--disable-telx' '--disable-vpx'
'--disable-vsxu' '--disable-wasapi' '--enable-alsa' '--enable-dc1394'
'--enable-dv1394' '--enable-linsys' '--enable-nfs' '--enable-omxil'
'--enable-udev' '--enable-v4l2' '--enable-wayland' '--enable-libva'
'--enable-vcd' '--enable-smbclient' '--disable-oss' '--enable-crystalhd'
'--enable-mmx' '--enable-sse' '--disable-neon' '--disable-altivec'
'build_alias=i686-linux-gnu' 'CFLAGS=-g -O2
-fdebug-prefix-map=/build/vlc-bMsdxu/vlc-3.0.6=. -fstack-protector-strong
-Wformat -Werror=format-security ' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now
-Wl,--as-needed' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2
-fdebug-prefix-map=/build/vlc-bMsdxu/vlc-3.0.6=. -fstack-protector-strong
-Wformat -Werror=format-security ' 'OBJCFLAGS=-g -O2
-fdebug-prefix-map=/build/vlc-bMsdxu/vlc-3.0.6=. -fstack-protector-strong
-Wformat -Werror=format-security'
[008ce110] main libvlc debug: searching plug-in modules
[008ce110] main libvlc debug: loading plugins cache file
/usr/lib/i386-linux-gnu/vlc/plugins/plugins.dat
[008ce110] main libvlc debug: recursively browsing
`/usr/lib/i386-linux-gnu/vlc/plugins'
[008ce110] main libvlc debug: plug-ins loaded: 511 modules
[008ce110] main libvlc debug: opening config file (/home/hb1/.config/vlc/vlcrc)
[008ce330] main logger debug: looking for logger module matching "any": 4
candidates
[008ce330] main logger debug: using logger module "console"
[008ce110] main libvlc debug: translation test: code is "C"
[008d00d8] main keystore debug: looking for keystore module matching "memory":
4 candidates
[008d00d8] main keystore debug: using keystore module "memory"
[008ce110] main libvlc debug: CPU has capabilities MMX MMXEXT SSE FPU
[0092ca28] main playlist debug: creating audio output
[0092e2e0] main audio output debug: looking for audio output module matching
"any": 6 candidates
[0092e2e0] vlcpulse audio output debug: using library version 10.0.0
[0092e2e0] vlcpulse audio output debug: (compiled with version 10.0.0,
protocol 32)
[0092e2e0] vlcpulse audio output error: PulseAudio server connection failure:
Connection refused
[0092e2e0] alsa audio output debug: Available ALSA PCM devices:
[0092e2e0] alsa audio output debug: Discard all samples (playback) or generate
zero samples (capture) (null)
[0092e2e0] alsa audio output debug: Intel 82801BA-ICH2, Intel 82801BA-ICH2
Default Audio Device (default:CARD=I82801BAICH2)
[0092e2e0] alsa audio output debug: Intel 82801BA-
Bug#877082: The .desktop file should register all supported file types
As a related feature request, I like to suggest, that the .desktop file for MuPDF should also register all other supported file types. MuPDF started as a simple PDF viewer, but it now also supports the formats XPS, OpenXPS and ePub. In my experience, it is a fast and reliable viewer for ePub files from the Project Gutenberg. For a better desktop integration, the .desktop file should register these file types as well. For ePub files it would be: MimeType=application/pdf;application/epub+zip; I don't know about XPS files, though. -- Regards, Hartmut Buhrmester
Bug#514862: bash: POSIX conformance: set -e and $(...)
This specific behavior is still found in "GNU bash, Version 4.4.12(1)-release" from Debian 9 Stretch, but a new shell option enables the more consistent behavior of other shells. Subshells for command substitutions do not automatically inherit the option "errexit". This must be enabled by another option "inherit_errexit". The manual page for the bash explains it like: inherit_errexit If set, command substitution inherits the value of the errexit option, instead of unsetting it in the subshell environment. This option is enabled when posix mode is enabled. Using this option gives the expected result: hb1@debian:~$ bash -c 'set -e ; z=$(false;echo foo) ; echo $z' foo hb1@debian:~$ echo $? 0 hb1@debian:~$ bash -c 'set -e ; shopt -s inherit_errexit ; z=$(false;echo foo) ; echo $z' hb1@debian:~$ echo $? 1 As mentioned in the manual, the POSIX mode also gives the expected result: hb1@debian:~$ bash --posix -c 'set -e ; z=$(false;echo foo) ; echo $z' hb1@debian:~$ echo $? 1 The Bash Reference Manual explains the difference: 42. Enabling POSIX mode has the effect of setting the inherit_errexit option, so subshells spawned to execute command substitutions inherit the value of the -e option from the parent shell. When the inherit_errexit option is not enabled, Bash clears the -e option in such subshells. The Bash Reference Manual can be installed with the Debian package "bash-doc". Then see: file:///usr/share/doc/bash/bashref.html#Bash-POSIX-Mode The option inherit_errexit is new in bash-4.4. The file /usr/share/doc/bash/NEWS.gz lists it under the first topic: This is a terse description of the new features added to bash-4.4 since the release of bash-4.3. [...] ii. inherit_errexit: a new `shopt' option that, when set, causes command substitutions to inherit the -e option. By default, those subshells disable -e. It's enabled as part of turning on posix mode. -- Regards, Hartmut Buhrmester
Bug#839008: scribus no longer finds DejaVu fonts
Apparently, this is caused by a bug in the FreeType library libfreetype6. An upstream bug report says: This is a bug caused by some FreeType versions which fail when loading some glyphs outlines and make us consider some fonts as broken. At least FreeType 2.6.0 to 2.6.3 are affected. FreeType 2.6.5 was fixed. Unfortunately Debian 9 has FreeType 2.6.3. If you upgrade FreeType to >= 2.6.5, you will have to clear scribus font cache. - https://bugs.scribus.net/view.php?id=15042
Bug#842378: Xfce needs a policykit authentication agent
The virtual package, which is provided by all policykit authentication agents, is now "polkit-1-auth-agent": hb1@debian:~$ aptitude show polkit-1-auth-agent No candidate version found for polkit-1-auth-agent Package: polkit-1-auth-agent State: not a real package Provided by: gnome-flashback (3.22.0-3), gnome-shell (3.22.3-3), lxpolkit (0.5.3-2), lxqt-policykit (0.11.1-1), mate-polkit (1.16.0-2), policykit-1-gnome (0.105-6), polkit-kde-agent-1 (4:5.8.4-1) A new dependency for Thunar could then be: thunar recommends lxpolkit|polkit-1-auth-agent But since the XDG autostart file for lxpolkit is effectively disabled by adding "Hidden=true", thunar would have to provide an own autostart file. It could be defined as /etc/xdg/autostart/xfpolkit.desktop with the contents: [Desktop Entry] Type=Application Name=LXPolKit for XFCE Comment=Policykit Authentication Agent Exec=lxpolkit TryExec=lxpolkit Icon=gtk-dialog-authentication OnlyShowIn=XFCE; Or, for the canonical solution, you could add the recommendation: thunar recommends policykit-1-gnome|polkit-1-auth-agent The file /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop is already configured for XFCE (but surprisingly not for GNOME): OnlyShowIn=XFCE;Unity;X-Cinnamon; I would add this dependency to Thunar, because the package thunar already recommends gvfs, and that uses policykit for authorization. -- Regards, Hartmut Buhrmester
Bug#867949: ebook-viewer crashes with "Illegal instruction"
Package: calibre Version: 2.75.1+dfsg-1 Other relevant packages: calibre-bin2.75.1+dfsg-1 python2.7 2.7.13-2 libqt5webkit5 5.7.1+dfsg-1 python-pyqt5.qtwebkit 5.7+dfsg-5 For debugging I also installed (for i386): calibre-bin-dbgsym 2.75.1+dfsg-1 python2.7-dbg 2.7.13-2 libqt5webkit5-dbg 5.7.1+dfsg-1 python-pyqt5.qtwebkit-dbg 5.7+dfsg-5 Kernel: Linux debian 4.9.0-3-686-pae #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) i686 GNU/Linux The ebook-viewer from the package calibre crashes with an "illegal instruction", while reading ebooks of type *.epub. This happens, for example, with the ebooks from Project Gutenberg at https://www.gutenberg.org/wiki/Main_Page . The crash does not happen immediately; the application starts normally and I can open an ebook of type *.epub. I can also browse through the pages. But when I start reading and stay at two subsequent page for some time, then the ebook-viewer may suddenly quit with an illegal instruction. It seems, that the ebook-viewer regularly recalculates the current reading position and safes it to a file. The next time it will reopen the file at the same position. But sometimes it seems to crash at this point. The ebook-viewer may also crash, when the application window is closed. This crash may get unnoticed during normal usage. But in the debugger, I still get the message: "Program terminated with signal SIGILL, Illegal instruction." I suspect, that the cause is again the recalculation of the reading position, to save it to a file. When the ebook-viewer is started in a terminal, I get the error "Illegal instruction". hb1@debian:~$ ebook-viewer Illegal instruction hb1@debian:~$ The logfiles /var/log/messages, /var/log/syslog und /var/log/kern.log contain these messages: Jun 29 22:52:30 debian kernel: [ 1529.008213] traps: ebook-viewer[1350] trap invalid opcode ip:a84cae95 sp:bfa65160 error:0 Jun 29 23:08:31 debian kernel: [ 2490.015276] traps: ebook-viewer[1407] trap invalid opcode ip:abf0e9a9 sp:bfaa6890 error:0 Jun 29 23:09:58 debian kernel: [ 2577.010756] traps: ebook-viewer[1440] trap invalid opcode ip:a8e34989 sp:bfeac550 error:0 Jun 29 23:28:20 debian kernel: [ 3679.067235] traps: ebook-viewer[1454] trap invalid opcode ip:aac0e9a9 sp:bf9d16d0 error:0 I created two backtraces with gdb, using the packages calibre-bin-dbgsym, python2.7-dbg, libqt5webkit5-dbg, and python-pyqt5.qtwebkit-dbg. Since /usr/bin/ebook-viewer is not a binary file, but a Python script, I used the approach: - start ebook-viewer in a terminal - get the process id of /usr/bin/python2.7 /usr/bin/ebook-viewer - start gdb - attach gdb to the process id - let the application continue - load an ebook in the ebook-viewer - read the ebook, until it crashes - get a backtrace Regards, Hartmut Buhrmester hb1@debian:~$ ps aux | grep ebook-viewer hb1 1543 23.8 26.2 337700 133500 pts/2 Sl+ 22:10 0:08 /usr/bin/python2.7 /usr/bin/ebook-viewer hb1 1552 0.0 0.1 4724 828 pts/0S+ 22:11 0:00 grep --color=auto ebook-viewer hb1@debian:~$ gdb GNU gdb (Debian 7.12-6) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) attach 1543 Attaching to process 1543 [New LWP 1546] [New LWP 1547] [New LWP 1548] [New LWP 1549] [New LWP 1550] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". 0xb779fcf9 in __kernel_vsyscall () (gdb) continue Continuing. [New Thread 0xa3c87b40 (LWP 1571)] [Thread 0xa3c87b40 (LWP 1571) exited] [New Thread 0xa3c87b40 (LWP 1572)] [New Thread 0xa3486b40 (LWP 1574)] [Thread 0xa3486b40 (LWP 1574) exited] [New Thread 0xa3486b40 (LWP 1577)] [Thread 0xa3486b40 (LWP 1577) exited] [Thread 0xa3c87b40 (LWP 1572) exited] Thread 1 "ebook-viewer" received signal SIGILL, Illegal instruction. 0xabeb9ef5 in ?? () (gdb) x 0xabeb9ef5 0xabeb9ef5: 0x04100ff2 (gdb) disassemble 0xabeb9ef5 No function contains specified address. (gdb) bt #0 0xabeb9ef5 in ?? () #1 0xb0c7e0fd in JSC::Interpreter::execute (this=0x0, program=0x0, callFrame=0x0, thisObj=0x0) at jit/JITCode.h:135 #2 0xb0d9de59 in JSC::evaluate (exe
Bug#842378: Xfce needs a policykit authentication agent
I think, in Debian 8 Jessie it worked like this: gvfs always depends on gvfs-daemons. gvfs-daemons recommends policykit-1-gnome, which was also a virtual package, provided by lxsession and mate-polkit. https://packages.debian.org/jessie/gvfs-daemons This dependency is lost in Debian 9 Stretch: https://packages.debian.org/stretch/gvfs-daemons But I don't think, that this recommendation should be restored. lxpolkit would be a much better solution for Xfce, if it could be launched automatically. Regards, Hartmut Buhrmester
Bug#842378: Xfce needs a policykit authentication agent
I also noticed, that I can mount external USB drives in Thunar, but I cannot mount partitions on the internal hard disk drive, which require root privileges. Then I get the same error message: "Authentication failed". The problem with Xfce and Thunar is, that they use gvfs and policykit, but they don't provide any policykit authentication agent. This agent is what displays the authorization dialog. It is usually left to the desktop environment to provide a policykit authentication agent, because it should match the user interface of the other applications: LXDE uses lxpolkit (GTK2) https://packages.debian.org/stretch/lxpolkit LXQt uses lxqt-policykit (Qt5) https://packages.debian.org/stretch/lxqt-policykit MATE uses mate-polkit (GTK3) https://packages.debian.org/stretch/mate-polkit GNOME uses policykit-1-gnome (GTK3) https://packages.debian.org/stretch/policykit-1-gnome Xfce just doesn't have any policykit authentication agent. I searched for it, but I didn't find any. Actually, lxpolkit works fine for Xfce, because it also uses GTK2 and is rather lightweight. It is not started automatically, because the file /etc/xdg/autostart/lxpolkit.desktop has the line "Hidden=true" in it. If it is launched manually, it will provide the authorization dialog for Thunar, and then I can mount any partitions, which requires root privileges. Any other policykit authentication agent will also work, because they all use the same dbus interface. So, to completely reveal this bug, you should do these steps: 1) Quit any other policykit agent, which may be running 2) Try to mount a partition in Thunar, which requires root privileges. This should fail at this point. 3) Launch lxpolkit 4) Try again to mount the partition. lxpolkit shows the dialog to enter the root password. I'm sure, that in Debian 8 Jessie, somehow policykit-1-gnome would be installed. Then at least one working authentication agent would be available. But with its dependency on GTK3, it was not the best solution for lightweight desktop environments. Regards, Hartmut Buhrmester
Bug#766838: ntpdate runs before dhcp-client has configured the network interface
Run Privileged Tasks. Nov 30 00:47:28 debian ntpdate[986]: adjust time server 131.234.137.64 offset -0.001715 sec Of course, for this test I disabled the script /etc/cron.daily/ntpdate, which I mentioned in my previous post. So a short break allows ntpdate to succeed without changing the way it is invoked, e.g. there is no need to create additional cron jobs or init scripts. -- Hartmut Buhrmester
Bug#766838: ntpdate runs before dhcp-client has configured the network interface
step time server 193.175.73.151 offset -5.518937 sec Nov 29 08:18:26 debian systemd[1]: Time has been changed -- Hartmut Buhrmester
Bug#843231: Openbox sets a dull gray background during startup
Package: openbox Version: 3.5.2-8 Openbox sets a dull gray background, if it is started with /usr/bin/openbox-session as a plain Openbox session (e.g. not within a LXDE session). The commands to set this background color can be found in the file /usr/lib/i386-linux-gnu/openbox-autostart, lines 3 - 12: # Set a background color BG="" if which hsetroot >/dev/null 2>/dev/null; then BG=hsetroot elif which esetroot >/dev/null 2>/dev/null; then BG=esetroot elif which xsetroot >/dev/null 2>/dev/null; then BG=xsetroot fi test -z $BG || $BG -solid "#303030" There is no way to disable or change the background color, or to set a background image instead. This causes a noticeable flicker during startup. For example, Debian 8 Jessie has nice teal background images for the boot loader grub, the display manager slim and the desktop background. The final background image would be /usr/share/images/desktop-base/lines-wallpaper_1920x1080.svg. There should be smooth transition during login, but setting a dull gray background just before the displaying the background image disrupts this transition. Most users will prefer to select a background image of their own, which could be set with nitrogen or feh. Or they might select a solid blue or green background color. Then the Openbox startup scripts should not set a gray background in-between, which can not be configured in any way. PS This issue has been reported before: openbox: filling the root window https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452539 That bug report was dismissed too soon, without anybody actually looking into the source code of the startup scripts. But it was all true. And to make this clear: I did not change the Openbox startup scripts in any way. This is just the default behavior of a plain Openbox session in Debian Jessie. -- Hartmut Buhrmester
Bug#821269: Incompatibility between task-german-desktop and firefox-esr-l10n-de
hunspell is the preferred spellchecker for many European languages, because it handles accents and umlauts better than myspell. The task-german-desktop recommends the dictionaries hunspell-de-de, hunspell-de-at and hunspell-de-ch. hunspell is also used by LibreOffice, and the package firefox-esr notably depends on libhunspell-1.3-0. But whenever I install the German localization firefox-esr-l10n-de, it wants to remove all hunspell dictionaries and install the corresponding myspell dictionaries instead. This would actually be a regression. In aptitude, I always have to cancel the removal and leave the dependencies of the package firefox-esr-l10n-de "unresolved". Of cause, the dictionaries are only recommended; but aptitude and apt-file are usually set to install all recommendations. So it would be a much better choice, if the package firefox-esr-l10n-de would recommend the hunspell dictionaries hunspell-de-de, hunspell-de-at, and hunspell-de-ch instead, just like task-german-desktop. Referenced packages: firefox-esr 45.4.0esr-1~deb8u2 firefox-esr-l10n-de 45.4.0esr-1~deb8u2 -- Hartmut Buhrmester
Bug#834405: Known bug with Zim and python-gtkspellcheck
Unfortunately, the package python-gtkspellcheck seems to be outdated, even in Debian unstable. It has one known bug, which I surely stumbled upon: Zim will crash, if bullet lists with URLs are used, as in: * http://www.example.com * http://bugs.example.com * http://forum.example.com * http://wiki.example.com This used to work fine with python-gtkspell, but python-gtkspellcheck 3.0 will crash, and it causes Zim to quit without warning. In the end, I had to install python-pip and update the package from source: pip install --upgrade pygtkspellcheck pip list | grep spell pygtkspellcheck (4.0.4) This was suggested in: https://github.com/koehlma/pygtkspellcheck/issues/29 There are a few related bug reports for Zim: https://bugs.launchpad.net/zim/+bug/1598138 https://bugs.launchpad.net/zim/+bug/1598830 -- Hartmut Buhrmester
Bug#835524: The German description of ack-grep is truncated in aptitude
My best guess is, that the term ".svn-Verzeichnissen" in the German description of ack-grep is erroneously interpreted as an embedded groff formating command. This makes about two lines of text missing. I assume, that the leading dot should be properly escaped in the German description. I still wonder, if aptitude could do some input filtering, to prevent this bug. Synaptic seems to do that. In Synaptic, the English description for ack-grep is: "Ack is designed as an alternative for 99% of the uses of grep. ack is intelligent about the files it searches. It knows about certain file types, based on both the extension on the file and, in some cases, the contents of the file. Ack ignores backup files and files under CVS and .svn directories. It also highlights matches to help you see where the match was. Ack uses perl regular expressions." The German description is: "Ack wurde als Alternative für 99% der Anwendungsfälle von grep entwickelt. Das Programm wählt die zu durchsuchenden Dateien intelligent aus. Es erkennt bestimmte Dateitypen anhand der Endung und in einigen Fällen anhand des Inhaltes der Datei. Ack ignoriert Sicherheitskopien und Dateien innerhalb von CVS- und svn-Verzeichnissen. Ebenso markiert es Treffer, damit Sie sehen, wo die Treffer gefunden wurden. Ack verwendet reguläre Ausdrücke von Perl." This looks almost correct, but the leading dot in ".svn" is missing. So Synaptic does some input sanitation and removes leading dots, which are not properly escaped. Then there would be two things to do: 1) The German description for ack-grep should be corrected and leading dots should be escaped. 2) aptitude should do some simple input sanitation like Synaptic. groff formating commands won't do much harm; but in other applications, this would be a serious bug, e.g. it could be compared to SQL injection bugs. -- Hartmut Buhrmester
Bug#835524: The German description is truncated in aptitude
Package: ack-grep Version: 2.14-4 Severity: minor The German description is truncated in aptitude. On the web page https://packages.debian.org/stretch/ack-grep , the German description is: "Ack wurde als Alternative für 99% der Anwendungsfälle von grep entwickelt. Das Programm wählt die zu durchsuchenden Dateien intelligent aus. Es erkennt bestimmte Dateitypen anhand der Endung und in einigen Fällen anhand des Inhaltes der Datei. Ack ignoriert Sicherheitskopien und Dateien innerhalb von CVS- und .svn-Verzeichnissen. Ebenso markiert es Treffer, damit Sie sehen, wo die Treffer gefunden wurden. Ack verwendet reguläre Ausdrücke von Perl." In aptitude, the German description is: hb@debian:~$ LC_ALL=de_DE.UTF-8 aptitude show ack-grep Paket: ack-grep Version: 2.14-4 Zustand: nicht installiert Priorität: optional Bereich: utils Verwalter: Debian Perl Group <pkg-perl-maintain...@lists.alioth.debian.org> Architektur: all Unkomprimierte Größe: 236 k Hängt ab von: libfile-next-perl (>= 1.10), perl Kollidiert mit: ack Ersetzt: ack Beschreibung: grep ähnelndes Programm speziell für umfangreiche Quellltextverzeichnisse Ack wurde als Alternative für 99% der Anwendungsfälle von grep entwickelt. Das Programm wählt die zu durchsuchenden Dateien intelligent aus. Es erkennt bestimmte Dateitypen anhand der Endung und in einigen Fällen anhand des Inhaltes der Datei. Ack ignoriert Sicherheitskopien und Dateien innerhalb von CVS- und die Treffer gefunden wurden. Ack verwendet reguläre Ausdrücke von Perl. Homepage: http://beyondgrep.com/ Markierungen: implemented-in::perl, interface::commandline, role::program, scope::utility Thus, the term ".svn-Verzeichnissen" breaks something in the parser. The English description looks okay, although it also uses the term ".svn directories" (but without hyphen). -- Hartmut Buhrmester
Bug#834405: zim should recommend gtkspellcheck, rather than gtkspell
Package: zim Version: 0.65-3 The package zim should recommend "gtkspellcheck", rather than "gtkspell". Zim can use both packages for its built-in spell checker. If both are installed in Debian 8 Jessie, "gtkspellcheck" will be preferred. On the other hand, "gtkspell" is no longer available in Debian 9 testing/Stretch. Therefore, "gtkspellcheck" should be recommended, From the upstream documentation: Dependencies: This plugin requires either of two libraries: "gtkspell" or "gtkspellcheck", if both are installed, the later is used. http://zim-wiki.org/manual/Plugins/Spell_Checker.html You can also tell that from the configuration dialog of the Spell Checker plugin. -- Hartmut Buhrmester
Bug#723002: kaffeine: Does not find TV tuner card
There are similar bug reports both in the Debian bug tracker (and others) and "upstream" at KDE. It seems, that Kaffeine often doesn't find the path to the /dev/dvb directory. This may be caused by incompatible versions of "udev". Try to add a symbolic link dvb -> /dev/dvb to your home directory: hb@debian:~$ ls -l lrwxrwxrwx 1 hb hb8 Aug 6 00:09 dvb -> /dev/dvb I used to need this on Debian 7 Wheezy. Note, that Kaffeine only supports digital TV, not analog TV. So the TV tuner card must be a dvb device. See: Bug 292138 - DvbLinuxDevice::startDevice uses wrong device path https://bugs.kde.org/show_bug.cgi?id=292138 FS#28017 - [kaffeine]: wrong device search path https://bugs.archlinux.org/task/28017 kaffeine: DvbLinuxDevice::startDevice uses wrong device path https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725282 -- Hartmut Buhrmester
Bug#832980: Case mismatch prevents xdg-autostart from handling autostart applications correctly
Package: obsession Version: 20140608-2 Case mismatch prevents xdg-autostart from handling autostart applications correctly xdg-autostart is a new utility, which is provided by the package obsession. It launches autostart applications from the directories /etc/xdg/autostart/ and ~/.config/autostart/. These autostart files can then be managed with lxsession-edit or a similar application. It even worked, when I tried it with Debian testing/Stretch alpha-6. But when I reinstalled the system with Debian testing/Stretch alpha-7, it stopped working. Neither OnlyShowIn=Openbox; nor NotShowIn=Openbox; worked anymore. I noticed, that there is a discrepancy in the descriptions: The man page in Debian says: "By default, xdg-autostart uses Openbox as desktop name." The upstream description says: "Make xdg-autostart use the OPENBOX environment by default, so you can use OnlyShowIn=OPENBOX in an autostart .desktop and it will work as expected." -- http://openbox.org/wiki/Openbox:Changelog#3.4.11 To check, which name is used during login and later, I created two small autostart files in ~/.config/autostart/ with the contents: hb@debian:~/.config/autostart$ cat Openbox.desktop [Desktop Entry] Type=Application Name=Openbox NoDisplay=true Exec=xmessage Openbox OnlyShowIn=Openbox; hb@debian:~/.config/autostart$ cat OPENBOX.desktop [Desktop Entry] Type=Application Name=OPENBOX NoDisplay=true Exec=xmessage OPENBOX OnlyShowIn=OPENBOX; During startup, the file OPENBOX.desktop is run. Later, when I run the script xdg-autostart manually without any command-line options, the file Openbox.desktop will be run. We can see, that Openbox was launched with the session name "OPENBOX" by calling "ps aux": hb@debian:~$ ps aux | grep -i openbox hb4457 0.1 3.6 76360 18396 ?Ssl 14:22 0:00 /usr/bin/openbox --startup /usr/lib/i386-linux-gnu/openbox-autostart OPENBOX This command comes from the script /usr/bin/openbox-session: # Run Openbox, and have it run the autostart stuff exec /usr/bin/openbox --startup "/usr/lib/i386-linux-gnu/openbox-autostart OPENBOX" "$@" The environment variable DESKTOP_SESSION will be set to "Openbox" later (but I don't know, where): hb@debian:~$ env | grep -i openbox DESKTOP_SESSION=Openbox The command xdg-autostart uses the session name "Openbox" internally, as described in the man page. This name can be found with "strings": hb@debian:~$ strings /usr/bin/xdg-autostart | grep -i openbox Openbox So, to summarize: During login, the command xdg-autostart uses the session name OPENBOX, which is passed as a command-line option. xdg-autostart itself uses Openbox internally, and this is also used in the environment variable DESKTOP_SESSION. This prevents xdg-autostart from cooperating with lxsession-edit, which honors the environment variable. Greetings, Hartmut Buhrmester
Bug#828061: libdvdnav4: breaks mplayer2 from wheezy
Package: libdvdnav4 Version: 5.0.1-1~bpo70+1 libdvdnav4 version 5.0.1 from Debian 7 wheezy-backports is not compatible with mplayer2 from Debian 7 wheezy. mplayer2 shows the error message: mplayer: error while loading shared libraries: libdvdnavmini.so.4: cannot open shared object file: No such file or directory Tested versions: libdvdnav4 5.0.1-1~bpo70+1 wheezy-backports mplayer22.0-554-gf63dbad-1+deb7u1 oldstable This bug has been discussed before <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774075>, and it was solved by adding a rule to prevent installing an incompatible version of libdvdnav4. For unknown reasons, this rule was deleted later, and only the rules "breaks mplayer/mencoder" are still there. These rules were introduced in bug report #759199. But recently libdvdnav4 5.0.1 was released in wheezy-backports, and it still is incompatible with mplayer2 from wheezy. libdvdnav4 version 5 does work with mplayer2 from Debian 8 Jessie. Fortunately, the old workaround of creating a symbolic link still works: ~# cd /usr/lib/i386-linux-gnu/ /usr/lib/i386-linux-gnu# ln -s libdvdnav.so.4 libdvdnavmini.so.4 -- Hartmut Buhrmester
Bug#827517: xul-ext-ublock-origin: Missing icons in uBlock's popup UI
The upstream bug report <https://bugzilla.mozilla.org/show_bug.cgi?id=1245811> is not about uBlock Origin. It is about resolving alias names in fontconfig files. But neither uBlock Origin nor Font Awesome use any fontconfig files. So these are different issues. The original extension at Mozilla.org [1] doesn't include a symbolic link for Linux. This wouldn't make much sense, since the relative path to the original file may be different on different distributions. Also, an extension on Mozilla.org can't require a font package on Linux. I don't think, that a Firefox extension can actually resolve Linux symbolic links. Extensions are written in JavaScript, XML and CSS, and they are run by Firefox. So I don't think, that extensions have an understanding of the underlying file system. The symbolic link was introduced on your side, possibly by an automatic system to search for duplicate files and replace them with symbolic links to their canonical installation paths. But it just doesn't work in this case. You should replace the symbolic link with the original font file, and then it works now, and not someday in Firefox 48. [1] https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/ Just download the xpi file from this site, and open it in Xarchiver. You will find, that the original extension has its own copy of the font file. -- Hartmut Buhrmester
Bug#827517: xul-ext-ublock-origin: Missing icons in uBlock's popup UI
Hello, I also noticed, that the icons from the extension uBlock Origin are missing, if the Debian version of the extension is installed, and I like to offer another explanation: When searching for instances of the Font Awesome, I found a symbolic link in the extension uBlock itself: /usr/share/xul-ext/ublock-origin/css/fonts/fontawesome-webfont.ttf The symbolic link uses a double redirection to finally point to the real font file at: /usr/share/fonts/truetype/font-awesome/fontawesome-webfont.ttf Now it seems, that the extension simply doesn't resolve that symbolic link. I deleted the symbolic link and replaced it with the original font file, and then everything worked fine! The complete protocol in the terminal looks like: root@debian:~# cd /usr/share/xul-ext/ublock-origin/css/fonts/ root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# ls -l insgesamt 12 lrwxrwxrwx 1 root root 60 Mai 3 13:01 fontawesome-webfont.ttf -> ../../../../fonts-font-awesome/fonts/fontawesome-webfont.ttf -rw-r--r-- 1 root root 4696 Mai 3 13:01 OFL.txt root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# ls -l fontawesome-webfont.ttf lrwxrwxrwx 1 root root 60 Mai 3 13:01 fontawesome-webfont.ttf -> ../../../../fonts-font-awesome/fonts/fontawesome-webfont.ttf root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# ls -l ../../../../fonts-font-awesome/fonts/fontawesome-webfont.ttf lrwxrwxrwx 1 root root 57 Jun 4 17:27 ../../../../fonts-font-awesome/fonts/fontawesome-webfont.ttf -> ../../fonts/truetype/font-awesome/fontawesome-webfont.ttf root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# readlink -f fontawesome-webfont.ttf /usr/share/fonts/truetype/font-awesome/fontawesome-webfont.ttf root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# ls -l /usr/share/fonts/truetype/font-awesome/fontawesome-webfont.ttf -rw-r--r-- 1 root root 152796 Mai 13 17:42 /usr/share/fonts/truetype/font-awesome/fontawesome-webfont.ttf root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# rm fontawesome-webfont.ttf root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# cp /usr/share/fonts/truetype/font-awesome/fontawesome-webfont.ttf . root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# ls -l insgesamt 160 -rw-r--r-- 1 root root 152796 Jun 20 22:46 fontawesome-webfont.ttf -rw-r--r-- 1 root root 4696 Mai 3 13:01 OFL.txt root@debian:/usr/share/xul-ext/ublock-origin/css/fonts# This was on Debian testing/Stretch, using the packages: firefox-esr 45.2.0esr-1 firefox-esr-l10n-de 45.2.0esr-1 xul-ext-ublock-origin 1.7.0+dfsg-1 -- Hartmut Buhrmester
