Bug#1030524: iwd segfaults in 2.2-1 no armhf on Rasperry Pi

[Patrick Häcker]

Hello Jonas,

> A new release 2.3-1 has just been released.  It would be helpful if you
> could test whether the problem has been fixed.
I can confirm that the Debian package 2.3-1 works without segfault (have it
running for > 10 hours without a problem). Thanks for the quick packaging!

> Upstream changes do not mention any RPi or ARM-related issues
> specifically, but mentions an off-by-one error which perhaps could lead
> to segfaults on your system.
If I had to guess, I would think that it was an ABI mismatch resulting from a
missing versioned dependency/conflict in one of the related packages and
somehow related to being a 32-bit ARM system, which is probably not that
common in combination with iwd (and amd64 got a binary-only update, which
armhf did not get).

If that should be true, the issue could reappear in the future. Nevertheless,
I suggest to close this bug and do a more detailed analysis only if the issue
really reappears in the future.

Kind regards
Patrick



signature.asc
Description: This is a digitally signed message part.

Bug#1030524: iwd segfaults in 2.2-1 no armhf on Rasperry Pi

[Patrick Häcker]

Package: iwd
Version: 2.2-1
Severity: important

Dear Maintainer,

on a Raspberry Pi 4 with armhf, version 2.2-1 segfaults when starting.
2.1-1 works without segfault.

(gdb) run
Starting program: /usr/libexec/iwd 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
No Diffie-Hellman support found, WPS will not be available
The following options are missing in the kernel:
CONFIG_KEY_DH_OPERATIONS
Wireless daemon version 2.2
Loaded configuration from /etc/iwd/main.conf
malloc(): invalid next size (unsorted)

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47  ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or 
directory.
(gdb) bt
#0  __libc_do_syscall ()
at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1  0xb6e8e42c in __pthread_kill_implementation (threadid=3070206496, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:43
#2  0xb6e8e470 in __pthread_kill_internal (signo=6, threadid=)
at pthread_kill.c:78
#3  0xb6e5d322 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0xb6e4e0ac in __GI_abort () at abort.c:79
#5  0xb6e85ac6 in __libc_message (action=action@entry=do_abort, 
fmt=) at ../sysdeps/posix/libc_fatal.c:155
#6  0xb6e967fa in malloc_printerr (str=) at malloc.c:5660
#7  0xb6e98da2 in _int_malloc (av=0xb6f507a4 , 
bytes=bytes@entry=60) at malloc.c:4001
#8  0xb6e99a5e in __GI___libc_malloc (bytes=60) at malloc.c:3315
#9  0xb6f77ab4 in l_malloc () from /lib/arm-linux-gnueabihf/libell.so.0
#10 0xb6f77bd0 in l_memdup () from /lib/arm-linux-gnueabihf/libell.so.0
#11 0xb6f7e284 in ?? () from /lib/arm-linux-gnueabihf/libell.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?) 

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (820, 'testing'), (400, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.15.84-v7l+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iwd depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-8
ii  libell0  0.56-2
ii  libreadline8 8.2-1.3

Versions of packages iwd recommends:
ii  dbus [dbus-system-bus]  1.14.4-1
ii  wireless-regdb  2022.06.06-1

iwd suggests no packages.

-- Configuration Files:
/etc/iwd/main.conf changed:
[General]
EnableNetworkConfiguration=true
[Network]
EnableIPv6=true


-- no debconf information

Bug#1023545: systemd --user and sd-pam processes keep running after logout (again)

[Patrick Häcker]

Package: systemd
Version: 252-2
Severity: normal

Dear Maintainer,

similar to #749268 there seems to be again the problem, that when logging
out, the systemd user process and sd-pam are not killed.

Take, e.g., this example:
# loginctl kill-session 34

# pgrep -a -u pat
11499 /lib/systemd/systemd --user
11500 (sd-pam)

# loginctl list-sessions
SESSION UID USER SEAT  TTY
 13   0 root seat0 tty2
 21   0 root seat0 tty2
 25   0 root seat0 tty2
 33   0 root seat0 tty2
 36   0 root seat0 tty2
 37 121 sddm seat0

6 sessions listed.

So although there is no logind session left, there are still the two user
processes around.

I added
KillUserProcesses=yes
but that did not help (is this an additional bug?).

Do I miss anything in order to kill the systemd user process automatically?

Kind regards
Patrick


-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (900, 'stable-security'), (900, 'testing'), (800, 'stable'), 
(500, 'unstable-debug'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  libacl12.3.1-1
ii  libaudit1  1:3.0.7-1.1+b1
ii  libblkid1  2.38.1-1.1+b1
ii  libc6  2.35-4
ii  libcap21:2.44-1
ii  libcryptsetup122:2.5.0-6
ii  libfdisk1  2.38.1-1.1+b1
ii  libgcrypt201.10.1-2
ii  libkmod2   30+20220905-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.2.7-0.1
ii  libmount1  2.38.1-1.1+b1
ii  libseccomp22.5.4-1+b1
ii  libselinux13.4-1+b2
ii  libssl33.0.7-1
ii  libsystemd-shared  252-2
ii  libsystemd0252-2
ii  libzstd1   1.5.2+dfsg-1
ii  mount  2.38.1-1.1+b1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.4-1
ii  systemd-timesyncd [time-daemon]  252-2

Versions of packages systemd suggests:
ii  libfido2-11.12.0-1
ii  libtss2-esys-3.0.2-0  3.2.0-1+b1
ii  libtss2-mu0   3.2.0-1+b1
pn  libtss2-rc0   
ii  policykit-1   122-1
pn  systemd-boot  
ii  systemd-container 252-2
pn  systemd-homed 
ii  systemd-resolved  252-2
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.4-1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 252-2
ii  libpam-systemd 252-2
ii  udev   252-2

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
SystemMaxUse=300M

/etc/systemd/logind.conf changed:
[Login]
KillUserProcesses=yes

/etc/systemd/system.conf changed:
[Manager]
DefaultTimeoutStartSec=20s
DefaultTimeoutStopSec=15s
DefaultDeviceTimeoutSec=20s


-- no debconf information

Bug#999596: sddm unnecessarily starts pulseaudio with sytemd user serssion

[Patrick Häcker]

The specific problem can be avoided with:

mkdir -p /var/lib/sddm/.config/systemd/user
chown -R sddm: /var/lib/sddm/.config/systemd
ln -s /dev/null /var/lib/sddm/.config/systemd/user/pulseaudio.service
ln -s /dev/null /var/lib/sddm/.config/systemd/user/pulseaudio.socket

Adding something like this to the sddm package would improve things
immediately.
Duplicating something like this into every display manager package seems
to be kind of wrong, however.


signature.asc
Description: This is a digitally signed message part.

Bug#999596: sddm unnecessarily starts pulseaudio with sytemd user serssion

[Patrick Häcker]

Package: sddm
Version: 0.19.0-3
Severity: normal

Dear Maintainer,

I am not really sure, if this is a sddm, pulseaudio or systemd bug, as all
three seem somehow involved:

Pulseaudio installs pulseaudio.service and pulseaudio.socket below
/usr/lib/systemd/user/ i.e. pulseaudio is started for every systemd user
session. As sddm is started with the user sddm, this starts a systemd user
session and therefore sddm starts pulseaudio.

This seems to be totally unnecessary, and leads to a warning when logging in
with the normal user. The shortened output of
"journalctl --priority warning --boot --output verbose" contains
PRIORITY=4
_TRANSPORT=journal
_UID=121
_GID=142
_AUDIT_LOGINUID=121
_SYSTEMD_OWNER_UID=121
_SYSTEMD_SLICE=user-121.slice
_SYSTEMD_UNIT=user@121.service
_PID=1010
MESSAGE=After module unload, module 'module-null-sink' was still loaded!
CODE_FILE=../src/pulsecore/module.c
CODE_FUNC=pa_module_unload_all
CODE_LINE=367
SYSLOG_IDENTIFIER=pulseaudio
_COMM=pulseaudio
_EXE=/usr/bin/pulseaudio
_CMDLINE=/usr/bin/pulseaudio --daemonize=no --log-target=journal

_SYSTEMD_CGROUP=/user.slice/user-121.slice/user@121.service/session.slice/pulseaudio.service
_SYSTEMD_USER_UNIT=pulseaudio.service
_SYSTEMD_USER_SLICE=session.slice
I confirmed that user sddm has a pulseaudio process running when no user is
logged in with SDDM.

sddm should most probably not start pulseaudio at all and maybe also not all
the other services in a systemd user session and possibly no systemd user
session in the beginning.

Kind regards
Patrick

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (900, 'stable-security'), (900, 'testing'), (800, 'stable'), 
(500, 'unstable-debug'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.79
ii  libc6 2.32-4
ii  libgcc-s1 11.2.0-10
ii  libpam0g  1.4.0-10
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5dbus5   5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libqt5network55.15.2+dfsg-12
ii  libqt5qml55.15.2+dfsg-8
ii  libqt5quick5  5.15.2+dfsg-8
ii  libstdc++611.2.0-10
ii  libsystemd0   249.5-2
ii  libxcb-xkb1   1.14-3
ii  libxcb1   1.14-3
ii  qml-module-qtquick2   5.15.2+dfsg-8
ii  x11-common1:7.7+23
ii  xauth 1:1.1-1
ii  xserver-xephyr [xserver]  2:1.20.11-1
ii  xserver-xorg [xserver]1:7.7+23
ii  xvfb [xserver]2:1.20.11-1

Versions of packages sddm recommends:
pn  haveged
ii  libpam-systemd 249.5-2
ii  sddm-theme-breeze [sddm-theme] 4:5.23.2-1
ii  sddm-theme-debian-breeze [sddm-theme]  4:5.23.2-1
ii  sddm-theme-debian-elarun [sddm-theme]  0.19.0-3
ii  sddm-theme-debian-maui [sddm-theme]0.19.0-3
ii  sddm-theme-maya [sddm-theme]   0.19.0-3

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.23.2-1
pn  qtvirtualkeyboard-plugin  

-- Configuration Files:
/etc/pam.d/sddm changed [not included]

-- debconf information:
* shared/default-x-display-manager: sddm
  sddm/daemon_name: /usr/bin/sddm

Bug#994057: #994057,libegl-mesa0: 21.2.1-2 with intel graphic card produces artifact on firefox-esr

[Patrick Häcker]

Hello,

> Testing with versions in between from snapshot.debian.org reveals that
> it's still OK with 21.1.6-1 and the issue starts with 21.2.0-1.
>
> Other related reports that look like they might be about the same
> problem, all related to Mesa 21.2 (I'm seeing artifacts in Firefox and
> in Konsole as described, as well as in other applications):
>
> https://forum.manjaro.org/t/konsole-tmux-rendering-problems-horizontal-stripes/86975
> https://bugs.launchpad.net/ubuntu/+source/kwin/+bug/1944951

I observe the same problem, although only with similar but not identical
hardware

> Graphics card info from 'hwinfo' output:
>
>  49: PCI 02.0: 0300 VGA compatible controller (VGA)
>Device Name: "Onboard IGD"
>Model: "Intel UHD Graphics 630 (Mobile)"
>Vendor: pci 0x8086 "Intel Corporation"
>Device: pci 0x3e9b "UHD Graphics 630 (Mobile)"
>Driver: "i915"
>Driver Modules: "i915"

Here is my (shortened) 'hwinfo' output:

24: PCI 02.0: 0300 VGA compatible controller (VGA)
  Device Name: "Onboard IGD"
  Model: "Intel HD Graphics 530"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x1912 "HD Graphics 530"
  Driver: "i915"
  Driver Modules: "i915"

I tested the Mesa upstream version from https://gitlab.freedesktop.org/mesa/
mesa/-/tree/main and can confirm the broken version there, too.

However: I didn't get any artifacts with mesa-21.3.0-rc4. I didn't bisect that
as mesa-21.2.5 has the artifacts and it does not matter which rc fixes it.

So we probably need our pinning in /etc/apt/preferences
> Package: libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0
> Pin: version 21.2.*
> Pin-Priority: -1
for some more days until 21.3.0 is released and if that gets packaged quickly,
the problem should probably be gone soon.

Kind regards
Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#996744: kde-config-gtk-style: Version mismatch segfaults kded5 repeatedly

[Patrick Häcker]

Hello Bernhard,

yes, thanks, it probably is the same, although in my journal I have traps from
kded5 and not from kde5, but this is probably a copy-paste issue in #996726.
Unfortunately, it's not mentioned, what the fix was, but when I look at the
diffoscope of 4:5.23.0-2 and 4:5.23.0-3 it looks like 4:5.23.0-3 would solve
this issue, too, as the main change is to tighten the breaks
>Breaks: kwin-common (<< 4:5.22.90), kwin-decoration-oxygen (<< 4:5.22.90),
kwin-style-breeze (<< 4:5.22.90), kwin-wayland (<< 4:5.22.90), kwin-wayland-
backend-drm (<< 4:5.22.90), kwin-wayland-backend-fbdev (<< 4:5.22.90), kwin-
wayland-backend-virtual (<< 4:5.22.90), kwin-wayland-backend-wayland (<<
4:5.22.90), kwin-wayland-backend-x11 (<< 4:5.22.90), kwin-x11 (<< 4:5.22.90)

So the specific problem is solved. The question is, whether the implicitly
mentioned general problem should be solved, too. Even with this change you'd
get a mix of 5.21 and 5.23 when installing a specific kde-plasma-desktop
package (see my list above in 996744). In this case this mix seems to work,
however, do we really have the man-power to support these mixes in the future?
And do we think that's what the user wants? Even in #996726 it's mentioned,
that you should always upgrade the entire stack. Why don't we set the package
metadata to guarantee that for the user and use our time for fixing real
problems instead of package version mismatches?

Kind regards
Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#996744: kde-config-gtk-style: Version mismatch segfaults kded5 repeatedly

[Patrick Häcker]

Package: kde-config-gtk-style
Version: 4:5.23.0-2
Severity: normal

Dear Maintainer,

I am not sure, whether this is a kded5 or kde-config-gtk-style packaging
problem, but both can currently be installed in an incompatible way leading
to repeatedly crashing kded5 (like 10 Dr.Konqi windows on login and some more
windows later) and a reduced user experience due to a missing kded5 process.

Being on testing and doing a
apt install kde-plasma-desktop kwin-addons -t unstable

updates the following packages to 5.23:
breeze-cursor-theme breeze kde-cli-tools-data kde-cli-tools
kde-style-breeze kdeplasma-addons-data kwin-addons kwin-common
kwin-data kwin-style-breeze kwin-wayland-backend-x11 kwin-wayland
kwin-x11 libcolorcorrect5 libkdecorations2-5v5 libkdecorations2private9
libkf5screen-bin libkf5screen7 libkf5sysguard-bin libkf5sysguard-data
libkfontinst5 libkfontinstui5 libksgrd9 libksignalplotter9
libksysguardformatter1 libksysguardsensorfaces1 libksysguardsensors1
libksysguardsystemstats1 libkwin4-effect-builtins1 libkwineffects13
libkwinglutils13 libkwinxrenderutils13 libkworkspace5-5
libnotificationmanager1 libplasma-geolocation-interface5
libprocesscore9 libprocessui9 libtaskmanager6abi1 libweather-ion7
milou plasma-dataengines-addons plasma-desktop-data plasma-desktop
plasma-runners-addons plasma-wallpapers-addons plasma-widgets-addons
plasma-workspace-data plasma-workspace-wayland plasma-workspace

However, the following packages stay on 5.21:
kde-config-gtk-style kde-config-sddm kde-style-oxygen-qt5 khotkeys-data
khotkeys kinfocenter kmenuedit kscreen ksshaskpass ksysguardd
kwin-decoration-oxygen kwrited libkdecorations2private8 liboxygenstyle5-5
liboxygenstyleconfig5-5 libpowerdevilcore2 libpowerdevilui5
oxygen-sounds plasma-pa plasma-theme-oxygen plasma-workspace-wallpapers
polkit-kde-agent-1 powerdevil-data powerdevil qml-module-org-kde-ksysguard
sddm-theme-breeze sddm-theme-debian-breeze systemsettings

That is not necessarily a problem (although probably not what the user
expects and a likely source of trouble). However, kded5=5.85.0-1 and
kde-config-gtk-style=4:5.23.0-2 lead to the described crash above within
plasma-workspace=4:5.23.0-3 (no crash with plasma-workspace=4:5.21.5-3).

The segfault occurs in the described package combination if ~/.config/kded5rc
contains
[Module-gtkconfig]
autoload=true
and there is no crash for autoload=false for the getconfig module.

Although I think the versioned dependency or break should be fixed, this is
the stacktrace for completeness:
Thread 1 "kded5" received signal SIGSEGV, Segmentation fault.
0x7fffeab92510 in KDecoration2::DecorationSettings::font() const () from 
/lib/x86_64-linux-gnu/libkdecorations2.so.5
(gdb) bt
#0  0x7fffeab92510 in KDecoration2::DecorationSettings::font() const () at 
/lib/x86_64-linux-gnu/libkdecorations2.so.5
#1  0x7fffeab92737 in 
KDecoration2::DecorationSettings::DecorationSettings(KDecoration2::DecorationBridge*,
 QObject*) ()
at /lib/x86_64-linux-gnu/libkdecorations2.so.5
#2  0x7fffeb24f3b2 in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#3  0x7fffeb24e93e in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#4  0x7fffeb24e278 in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#5  0x7fffeb246ef5 in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#6  0x7fffeb241e0b in GtkConfig::setWindowDecorationsAppearance() const ()
at /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#7  0x7fffeb242781 in GtkConfig::applyAllSettings() const () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#8  0x7fffeb242ba4 in GtkConfig::GtkConfig(QObject*, QList 
const&) ()
at /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#9  0x7fffeb2434aa in  () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#10 0x77006a52 in KPluginFactory::create(char const*, QWidget*, 
QObject*, QList const&, QString const&) ()
at /lib/x86_64-linux-gnu/libKF5CoreAddons.so.5
#11 0x5556019d in  ()
#12 0x55561119 in  ()
#13 0x555615a3 in  ()
#14 0xb121 in  ()
#15 0x766a8e4a in __libc_start_main (main=
0xab10, argc=1, argv=0x7fffdec8, init=, 
fini=, rtld_fini=, stack_end=0x7fffdeb8) at 
../csu/libc-start.c:314
#16 0xb53a in  ()

Kind regards
Patrick

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (900, 'stable-security'), (900, 'testing'), (800, 'stable'), 
(500, 'unstable-debug'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kde-config-gtk-style depends on:
ii  libc6 2.32-4
ii  libglib2

Bug#996622: mdadm prints warning on every boot due to evifarfs on non-EFI system

[Patrick Häcker]

Hi Felix,

> > force_load efivarfs || true
>
> That invokes the following function when the initramfs is
> created (from /usr/share/initramfs-tools/hook-functions):
>
> # force_load module [args...]
> force_load()
> {
> manual_add_modules "$1"
> echo "${@}" >>"${DESTDIR}/conf/modules"
> }
>
> The hook could check if the module exists, but it seems more robust to
> do it at boot time.
>
> Is this a bug in mdadm or in initramfs-tools?

I am not sure. I think it's a question of expectation. When you have a UEFI
system and the efivarfs module cannot be loaded, then you'd expect the error.
However, when you have a non-UEFI system, you do not expect any message at
all. So I think it's mdadm's job to state this policy and ideally initramfs-
tools would make it as simple as possible to do so.

Maybe it's possible for mdadm to execute something similar to
manual_add_modules (being part of force_load in hook-functions) itself, which
does the right thing? If that works, it might be possible to rewrite this in a
more general way and make it available in initramfs-tools.

It guess, this is not the first time, that a module must be loaded
conditionally in the initramfs. Maybe bringing the issue to debian-devel might
lead to the solution.

Kind regards
Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#996670: libkdecorations2-5v5 migrated to testing too early breaking Plasma

[Patrick Häcker]

Package: libkdecorations2-5v5
Version: 4:5.23.0-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

as of 2021-10-17T06:09:05+00:00 Debian testing contains 4:5.23.0-2, although
the rest of Plasma is still on 5.21. Therefore, apt update installs
libkdecorations2-5v5=4:5.23.0-2 which breaks login and renders the computer
useless for normal users. A downgrade to version 4:5.21.5-2 fixes the problem.

Of course, you could also argue that normal users should not run testing and
I am sure this bug gets fixed implicitly when the rest of Plasma migrates,
so severity normal would also be sensible, depending on how you look at it.
Fixing these kind of transition problems can safe a lot of users' time and
therefore encourage more advanced users to run testing and report real bugs
early on and therefore reduce freeze time.

This is closely related to #974112, but as #974112 is specific to an older
transition, I wanted to create a generic bug report.

I am not sure, how the fix ideally should look like, but it most likely includes
either a (versioned) dependency or a conflict.

Kind regards
Patrick


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (900, 'stable-security'), (900, 'testing'), (800, 'stable'), 
(500, 'unstable-debug'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libkdecorations2-5v5 depends on:
ii  libc6 2.32-4
ii  libkdecorations2private8  4:5.21.5-2
ii  libkf5i18n5   5.86.0-1
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libstdc++611.2.0-9

libkdecorations2-5v5 recommends no packages.

libkdecorations2-5v5 suggests no packages.

-- no debconf information

Bug#996622: mdadm prints warning on every boot due to evifarfs on non-EFI system

[Patrick Häcker]

Package: mdadm
Version: 4.2~rc2-7
Severity: normal

Dear Maintainer,

due to #962844 and #995093, /usr/share/initramfs-tools/hooks/mdadm does a
force_load efivarfs || true
which results on trying to load efivarfs on every boot. However, this
obviously does not work on a non-UEFI system and therefore there is ai very
prominent warning printet on the screen on every boot:
modprobe: ERROR: could not insert 'efivarfs': No such device

One idea might be to check whether /sys/firmware/efi exists and only doing the
force_load if it exists. That should be a huge improvement compared to the
current situation. Of course, it will fail when the user switches from a
non-UEFI system to a UEFI system. Using modprobe while redirecting modprobe's
stderr to /dev/null might be another option.

Kind regards
Patrick

Bug#985665: fish: new upstream release 3.2.1

[Patrick Häcker]

On Sun, 21 Mar 2021 18:53:12 +0100 Patrice Duroux 
wrote:
> Package: fish
> Version: 3.1.2-3
> Severity: wishlist
>
Dear Maintainer,

meanwhile, version 3.3.1 is available for some time.

Kind regards
Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#992760: ksystemtray: cannot be started, wrong version

[Patrick Häcker]

Hi,

> > ii  libkf5plasma5 5.78.0-3
>
> The problem is that this packages (and several others) from the
> frameworks are not updated.
>
> I guess we have to introduce a breaks somewhere ... this incompatibility
> is somehow surprising, because it is not documented in the CMakeList
> files - at least as far I see...
>
> > So better wait for a newer version...
>
> No, wait for all frameworks being updated ...

if you do not want to wait:
apt install -t unstable $(apt list --installed | grep 5.78.0-3 | cut -d/ -f1)
did the trick for me.
Of course you need testing and unstable in /etc/apt/sources.list and an
appropriate Pin-Priority in /etc/apt/preferences in order that this makes any
sense (e.g. 900 for testing and 400 for unstable).

This installed the following four packages:
libkf5plasmaquick5 libkf5runner5 libkf5plasma5 plasma-framework

The only other packages my system finds with
apt list | grep 5.78.0-3
are
libkf5plasma-dev libkf5plasma-doc libkf5runner-dev libkf5runner-doc qml-
module-org-kde-runnermodel

I hope this helps adding a versioned dependency or introducing a breaks.

Thanks a lot, Norbert and all the relevant Debian maintainers, for all your
work regarding KDE software packaging in Debian. The improved availability is
more than welcome!

Kind regards
Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#945008: k2pdfopt: does not read all pages with some pdfs(no matter what -p)

[Patrick Häcker]

This is the link for k2pdfopt I wanted to send (needs to solve a CAPTCHA on 
the left): https://www.willus.com/k2pdfopt/download/

Am Sonntag, 10. Januar 2021, 07:27:40 CET schrieb Patrick Häcker:
> Hi,
> 
> I can confirm the bug for
> http://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/
> entropy.pdf
> with only exactly converting 10 pages from the source file.
> 
> The bug does not occur with the k2pdfopt version from
> http://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/
> entropy.pdf
> so it really seems to be a Debian package problem.
> 
> Kind regards
> Patrick



signature.asc
Description: This is a digitally signed message part.

Bug#945008: k2pdfopt: does not read all pages with some pdfs(no matter what -p)

[Patrick Häcker]

Hi,

I can confirm the bug for
http://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/
entropy.pdf
with only exactly converting 10 pages from the source file.

The bug does not occur with the k2pdfopt version from
http://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/
entropy.pdf
so it really seems to be a Debian package problem.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#973411: spectre-meltdown-checker: Inconsistent output compared to Debian's security tracker

[Patrick Häcker]

Package: spectre-meltdown-checker
Version: 0.43-3
Severity: normal

Dear Maintainer,

I get two vulnerabilities shown when using spectre-meltdnown-checker for this
Skylake system:

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this 
> vulnerability)

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability:  N/A 
> STATUS:  VULNERABLE  (your CPU supports SGX and the microcode is not up to 
> date)

Both indicate that updated CPU micorcode is needed.

However, intel-microcode is installed with version 3.20200616.1 and both
https://security-tracker.debian.org/tracker/CVE-2018-3640
and
https://security-tracker.debian.org/tracker/CVE-2018-3615
indicate that the vulnerability is fixed with version 3.20200616.1 for
bullseye/sid.

There is a lot of fuzz about being quantum-safe, but I do not think that they
refer to being vulnerable and not being vulnerable at the same time. ;-)

So who is right? Is it spectre-meltdown-checker or the security tracker? Or
are really both right and there is some information missing (like that it is
fixed but only with a UEFI/BIOS update)?

Kind regards
Patrick

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 'unstable-debug'), (400, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#973048: ardentryst: Missing dependency on python3-future

[Patrick Häcker]

Package: ardentryst
Version: 1.71-7
Severity: normal

Dear Maintainer,

I cannot start ardentryst any more:

pat@mmm ~> cd /usr/share/games/ardentryst
   /usr/bin/python3 /usr/share/games/ardentryst/ardentryst.py
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
Traceback (most recent call last):
  File "/usr/share/games/ardentryst/ardentryst.py", line 26, in 
from past.builtins import cmp
ModuleNotFoundError: No module named 'past'

Installing the package python3-future fixes it. So ardentryst should depend
on python3-future.

Kind regards
Patrick

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 'unstable-debug'), (400, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ardentryst depends on:
ii  fonts-freefont-ttf  20120503-10
ii  python3 3.8.2-3
ii  python3-pygame  1.9.6+dfsg-4

ardentryst recommends no packages.

ardentryst suggests no packages.

-- no debconf information

Bug#962524: apt: history.log contains architecture-specific entries for architecture-all packages

[Patrick Häcker]

> In summary, this is not a bug - the log uses the package architecture, not
> the version architecture. If you need the version architecture, you need
> to reconstruct it in a different way.

Thanks for the information, I understand, that this is not a bug and already
found a workaround.
Is there some documentation about the difference between package architecture
and version architecture?

What I still miss to understand: Implementation details aside, would there be
any disadvantage, if apt used the version architecture for foo:all instead of
the package architecture in history.log?
In my (obviously incomplete) understanding the user could always conclude from
"all" that they can use any architecture, but cannot conclude from "amd64"
whether the package is architecture-independent.

Kind regards
Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#855549: apt should have a history command which shows what updates/upgrades and removals were done to packages

[Patrick Häcker]

You can use apt-revert from Salsa (https://salsa.debian.org/PatH/apt-revert)
to view the history.

Kind regards
Patrick

On Mon, 20 Feb 2017 06:25:47 +0530 =?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?
=  wrote:
> Package: apt
> Version: 1.4~rc1
> Severity: wishlist
>
> Dear Maintainer,
>
> Looking at apt --help it gives the following options -
>
> [$] apt --help
>
> apt 1.4~rc1 (amd64)
> Usage: apt [options] command
>
> apt is a commandline package manager and provides commands for
> searching and managing as well as querying information about packages.
> It provides the same functionality as the specialized APT tools, like
> apt-get and apt-cache, but enables options more suitable for
> interactive use by default.
>
> Most used commands:
>   list - list packages based on package names
>   search - search in package descriptions
>   show - show package details
>   install - install packages
>   remove - remove packages
>   autoremove - Remove automatically all unused packages
>   update - update list of available packages
>   upgrade - upgrade the system by installing/upgrading packages
>   full-upgrade - upgrade the system by removing/installing/upgrading
packages
>   edit-sources - edit the source information file
>
> See apt(8) for more information about the available commands.
> Configuration options and syntax is detailed in apt.conf(5).
> Information about how to configure sources can be found in sources.list(5).
> Package and version choices can be expressed via apt_preferences(5).
> Security details are available in apt-secure(8).
>  This APT has Super Cow Powers.
>
> While all the above options are good, one option which is missing and
> should be there is $ apt history which gives an output from
>
> Doing a less /var/log/apt/history.log gives the following -
>
> Start-Date: 2017-02-20  05:07:11
> Requested-By: shirish (1000)
> Upgrade: libmpx0:amd64 (5.4.1-4, 5.4.1-5), libgcj16:amd64 (5.4.1-4,
> 5.4.1-5), libgcc-5-dev:amd64 (5.4.1-4, 5.4.1-5),
> gcj-5-jre-headless:amd64 (5.4.1-4, 5.4.1-5), cpp-5:amd64 (5.4.1-4,
> 5.4.1-5), binutils:amd64 (2.27.90.20170124-2, 2.27.90.20170218-1),
> libgcj16-awt:amd64 (5.4.1-4, 5.4.1-5), gcj-5-jre:amd64 (5.4.1-4,
> 5.4.1-5), libgfortran-5-dev:amd64 (5.4.1-4, 5.4.1-5), libasan2:amd64
> (5.4.1-4, 5.4.1-5), gcc-5-base:amd64 (5.4.1-4, 5.4.1-5),
> gcj-5-jre-lib:amd64 (5.4.1-4, 5.4.1-5), libstdc++-5-dev:amd64
> (5.4.1-4, 5.4.1-5), g++-5:amd64 (5.4.1-4, 5.4.1-5), gcc-5:amd64
> (5.4.1-4, 5.4.1-5), gfortran-5:amd64 (5.4.1-4, 5.4.1-5)
> End-Date: 2017-02-20  05:08:44
>
> Now as can be seen from the excerpt I took from /var/log/apt/history.log
>
> Would be nice if the output could be prettifed, means no package


signature.asc
Description: This is a digitally signed message part.

Bug#962524: apt: history.log contains architecture-specific entries for architecture-all packages

[Patrick Häcker]

Package: apt
Version: 2.1.6
Severity: normal

Dear Maintainer,

the log file /var/log/apt/history.log shows all packages with the main
architecture even for architecture:all packages as in the following example:
> Downgrade: libkf5libkleo-data:amd64 (4:20.04.1-1, 4:19.08.3-1)

But executing
> apt-cache show libkf5libkleo-data | grep Architecture
results in
> Architecture: all

I did not find any documentation about the log syntax, so I am not sure if
this a bug or a whishlist. However, I expected the information after the
colon to be consistent with the package's architecture entry. As it's
currently implemented it seems to me to be rather redundant to repeat the
default architecture again and again in the log file (so it might not have
been a deliberate implementation choice that's why I decided for severity
normal).

Having the correct architecture in the log file would simplify to get the
information for calling debsnap.

Thanks for considering.

Kind regards
Patrick

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-.*-5\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-.*-5\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-.*-5\.6\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-5\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-5\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-5\.6\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-5\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-5\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-5\.6\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.6\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.5\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.6\.0-2-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; 
fi";
APT::Periodic "";
APT::Periodic::RandomSleep "0";
APT::Color "true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
A

Bug#921878: libcec4: Consider building libcec with Raspberry Pi support

[Patrick Häcker]

Package: libcec4
Version: 4.0.4.1~stretch
Severity: wishlist

Dear Maintainer,

the Debian package of libcec does not support the Raspberry Pi's (RPI) HDMI
port in version 4.0.3+dfsg1-1.
Version 4.0.4.1~stretch in Rasbian does support it (you can find it here:
http://archive.raspberrypi.org/debian/pool/main/libc/libcec/).

Please consider if it is possible to build the package with RPI support in
Debian, too, as done for the Rasbian package (at least on armhf).

If you are interested in that change and want to have help, please reach me.
I guess it might be trivial when diffing both source packages.

Kind regards
Patrick

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'stable'), (500, 'stable-updates')
Architecture: armhf (armv7l)

Kernel: Linux 4.19.17-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
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: systemd (via /run/systemd/system)

Versions of packages libcec4 depends on:
ii  libc62.28-6
ii  libgcc1  1:8.2.0-16
ii  libp8-platform2  2.1.0.1+dfsg1-2
ii  libstdc++6   8.2.0-16
ii  libudev1 240-5
ii  libx11-6 2:1.6.7-1
ii  libxrandr2   2:1.5.1-1

libcec4 recommends no packages.

libcec4 suggests no packages.

-- no debconf information

Bug#906548: chromium: Chromium crashes with SEGV on startup on RPI

[Patrick Häcker]

Hi Tom,

> On 20 Dec 2018, at 17:10, Patrick Häcker wrote:
> > Maybe you can elaborate on your working setup.
> 
> I've just run a dist-upgrade and 72.0.3626.7-6 installed and works.

I can confirm, that version 72.0.3626.7-6 is fixing the issue. Thanks a lot for 
pointing me to the unstable version.

So as soon as this version enters testing, this bug report can be closed.

Thanks!
Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Patrick Häcker]

Am Freitag, 4. Januar 2019, 12:22:46 CET schrieb Michael Biebl:
> Am 04.01.19 um 11:48 schrieb Patrick Häcker:
> > Hello,
> > 
> >> Can you post the output of
> >> ls -ld /var/lib/systemd/timesync
> >> ls -la /var/lib/private/systemd/
> > 
> > root@mmm /h/pat# ls -ld /var/lib/systemd/timesync
> > lrwxrwxrwx 1 root root 27 Jan  3  2018 /var/lib/systemd/timesync -> ../
> > private/systemd/timesync/
> > 
> > root@mmm /h/pat# ls -la /var/lib/private/systemd/
> > insgesamt 12
> > drwxr-xr-x 3 root root 4096 Jan  3  2018 ./
> > drwx-- 3 root root 4096 Jan  3  2018 ../
> > drwxr-xr-x 2 systemd-timesync systemd-timesync 4096 Okt 19  2017 timesync/
> 
> Hm, but this directory is writable by systemd-timesync, so
> systemd-timesyncd should have no problem with updating the timestamp.

Yes, /var/lib/private/systemd is writable. However, /var/lib/private is not 
(note the ".." entry in the listing above). And as permission is denied on 
that directory level, the subdirectory systemd can't be accessed neither.
With DynamicUser systemd would use the trick to have the separate mount 
namespace with the extended permissions due to a tmpfs on /var/lib/private, 
but as that's not active it does not save the day.

> For completeness sake, can you also post the output of
> stat /var/lib/systemd/timesync/clock
> Make that
> stat /var/lib/private/systemd/timesync/clock

root@mmm /h/pat# env LANG=EN stat /var/lib/systemd/timesync/clock
  File: /var/lib/systemd/timesync/clock
  Size: 0   Blocks: 0  IO Block: 4096   regular empty file
Device: 801h/2049d  Inode: 789553  Links: 1
Access: (0644/-rw-r--r--)  Uid: (  111/systemd-timesync)   Gid: (  135/
systemd-timesync)
Access: 2019-01-01 11:13:04.934514106 +0100
Modify: 2019-01-01 11:13:04.934514106 +0100
Change: 2019-01-01 11:13:04.934514106 +0100
 Birth: -

> (I missed that you already deleted /var/lib/systemd/timesync/)
Please note, that I somewhat mix the output from the two affected systems here 
due to system downtime of one system. This is quite practical here, as I 
haven't deleted the symbolic link on the system with the output above. So UID, 
GID and timestamps are a bit inconsistent along my entries to this bug report, 
but the rest should basically be identical.

I think the state to see the problem is quite reproducible: First install 
systemd 239 and afterwards install systemd 240, i.e. I can recreate whatever 
state you need.

Kind regards and thanks
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Patrick Häcker]

Hello,
 
> Can you post the output of
> ls -ld /var/lib/systemd/timesync
> ls -la /var/lib/private/systemd/

root@mmm /h/pat# ls -ld /var/lib/systemd/timesync
lrwxrwxrwx 1 root root 27 Jan  3  2018 /var/lib/systemd/timesync -> ../
private/systemd/timesync/

root@mmm /h/pat# ls -la /var/lib/private/systemd/
insgesamt 12
drwxr-xr-x 3 root root 4096 Jan  3  2018 ./
drwx-- 3 root root 4096 Jan  3  2018 ../
drwxr-xr-x 2 systemd-timesync systemd-timesync 4096 Okt 19  2017 timesync/

> This will only be a problem for users of unstable/testing, not for users
> who upgrade from stretch → buster directly, as timesyncd in stretch does
> not use DynamicUser=true.
> 
> That said, we should probably add some cleanup routines to remove
> /var/lib/systemd/timesync and
> /var/lib/private/systemd/timesync
> and let the directories be recreated
> 
> Checking the other services, for which DynamicUser=true was dropped,
> like systemd-resolved, they don't appear to be affected afaics as they
> don't use StateDirectory.
This sounds all very plausible and is in line with my understanding, i.e. an 
rm is all which is needed. I just tested it and /var/lib/systemd/timesync is 
really recreated with the correct permissions after deletion when starting 
timesyncd.

Kind regards and thanks
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Patrick Häcker]

Hi,

the problem seems to be mixing two approaches in an incompatible way:

1) /var/lib/systemd/timesync can either be a directory (a) or a symlink to
/var/lib/private/systemd/timesync (b)

2) systemd-timesyncd.service may either contain DynamicUser=yes (a) or not 
(b).

1a together with 2b should work as should 1b together with 2a.

With systemd 240-2 the combination 1b-2b seems to be used, which cannot work.

I just tested both combinations 1a-2b and 1b-2a and they work both.

But which package created the symlink (i.e. the transition from 1a to ab)? 
According to the symlink's timestamp (do not confuse with the clock's 
timestamp) and dpkg's log this was due to the upgrade from systemd version 
232-25+deb9u6 to 239-15.

So I guess the least intrusive change is to have systemd change /var/lib/
systemd/timesync back to being a directory. This only breaks if a user 
manually switched to DynamicUser, so it might be worth mentioning in the 
changelog.

Kind regards
Patrick

On Fri, 04 Jan 2019 07:27:05 +0100 =?utf-8?q?Patrick_H=C3=A4cker?= 
 wrote:
> Package: systemd
> Version: 240-2
> Severity: normal
> 
> Dear Maintainer,
> 
> after updating systemd from 239-15 to 240-2 timesyncd stopped touching
> /var/lib/private/systemd/timesync/clock any more and its time stamps
> stay at the time of the package upgrade.
> Additionally the file is no longer used to update the system time after
> reboot, using the compile time instead until an NTP server is available
> (if no RTC is available).
> 
> This is reproducable for the two systems I tested (the other is on amd64).
> On both systems the last timestamp is the time of the package upgrade
> according to the dpkg log.
> Downgrading to 239-15 solves the issue and the file is updated again.
> 
> Using
> > systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M 
printk.devkmsg=on
> as linux command line boot parameter, the following error appears in the 
log:
> > systemd-timesyncd[309]: Failed to create state directory, ignoring: 
Permission denied
> 
> So the open of /var/lib/systemd/timesync in timesyncd.c, line 37, fails. The
> reason is probably
> > ls -ld /var/lib/private
> > drwx-- 3 root root 4096 Dez 20 16:03 /var/lib/private/
> as timesyncd runs with UID/GUI systemd-timesync:systemd-timesync.
> 
> The following article might be related (modulo all the noise):
> https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimesyncdFailure
> 
> Kind regards
> Patrick
> 
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (800, 'testing'), (700, 'stable'), (500, 'stable-updates')
> Architecture: armhf (armv7l)
> 
> Kernel: Linux 4.19.8-v7+ (SMP w/4 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: systemd (via /run/systemd/system)
> 
> Versions of packages systemd depends on:
> ii  adduser  3.118
> ii  libacl1  2.2.52-3+b1
> ii  libapparmor1 2.13.1-3+b1
> ii  libaudit11:2.8.4-2
> ii  libblkid12.33-0.2
> ii  libc62.28-2
> ii  libcap2  1:2.25-1.2
> ii  libcryptsetup12  2:2.0.6-1
> ii  libgcrypt20  1.8.4-4
> ii  libgnutls30  3.6.5-2


signature.asc
Description: This is a digitally signed message part.

Bug#918190: systemd: timesyncd stopped updating clock file after package update

[Patrick Häcker]

Package: systemd
Version: 240-2
Severity: normal

Dear Maintainer,

after updating systemd from 239-15 to 240-2 timesyncd stopped touching
/var/lib/private/systemd/timesync/clock any more and its time stamps
stay at the time of the package upgrade.
Additionally the file is no longer used to update the system time after
reboot, using the compile time instead until an NTP server is available
(if no RTC is available).

This is reproducable for the two systems I tested (the other is on amd64).
On both systems the last timestamp is the time of the package upgrade
according to the dpkg log.
Downgrading to 239-15 solves the issue and the file is updated again.

Using
> systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M 
> printk.devkmsg=on
as linux command line boot parameter, the following error appears in the log:
> systemd-timesyncd[309]: Failed to create state directory, ignoring: 
> Permission denied

So the open of /var/lib/systemd/timesync in timesyncd.c, line 37, fails. The
reason is probably
> ls -ld /var/lib/private
> drwx-- 3 root root 4096 Dez 20 16:03 /var/lib/private/
as timesyncd runs with UID/GUI systemd-timesync:systemd-timesync.

The following article might be related (modulo all the noise):
https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimesyncdFailure

Kind regards
Patrick


-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'stable'), (500, 'stable-updates')
Architecture: armhf (armv7l)

Kernel: Linux 4.19.8-v7+ (SMP w/4 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: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.1-3+b1
ii  libaudit11:2.8.4-2
ii  libblkid12.33-0.2
ii  libc62.28-2
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.6-1
ii  libgcrypt20  1.8.4-4
ii  libgnutls30  3.6.5-2
ii  libgpg-error01.33-3
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-3
ii  libkmod2 25-2
ii  liblz4-1 1.8.2-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.33-0.2
ii  libpam0g 1.1.8-3.8
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  240-2
ii  mount2.33-0.2
ii  util-linux   2.33-0.2

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  240-2

Versions of packages systemd suggests:
ii  policykit-10.105-23
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 240-2

-- Configuration Files:
/etc/systemd/system.conf changed:
[Manager]
DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s


-- no debconf information

Bug#906548: chromium: Chromium crashes with SEGV on startup on RPI

[Patrick Häcker]

Hi Tom,

you wrote on the upstream bug tracker that you have resolved the issue with an 
upgrade and version 70.0.3538.67-2. Did you upgrade to testing? Maybe you can 
elaborate on your working setup.

I upgraded to testing, but to no avail. As there is no testing or unstable 
armhf version of chromium as of today, I wouldn't expect a working chromium in 
testing/unstable on armhf if it's really a compiler issue.

Kind regards
Patrick

On Fri, 24 Aug 2018 14:12:53 +0100 Thomas Stewart  
wrote:
> Hi,
> 
> I have reported this upstream:
> https://bugs.chromium.org/p/chromium/issues/detail?id=877480
> 
> Kind Regards
> --
> Tom
> 
> 
> 


signature.asc
Description: This is a digitally signed message part.

Bug#906588: chromium: Chromium crashes with SEGV on startup on Rasperry Pi

[Patrick Häcker]

Package: chromium
Version: 68.0.3440.75-1~deb9u1
Severity: important

Dear Maintainer,

Chromium on Debian stable (68.0.3440.75-1~deb9u1r) crashes with a
SEGV_MAPERR on startup on a Raspberry Pi since the last security update
(the system is Debian stable with some Raspbian packages).

Version 67.0.3396.87-1~deb9u1 works.

Unfortunately, I couldn't find a dbgsym package for 68.0.3440.75-1~deb9u1r
due to the security update. Please point me to the correct location.
Until then, this is the full output with --debug including  a stacktrace:

[7412:7429:0818/141457.911561:ERROR:browser_gpu_channel_host_factory.cc(119)] 
Failed to launch GPU process.
[7412:7501:0818/141501.276853:ERROR:bus.cc(394)] Failed to connect to the bus: 
Could not parse server address: Unknown address type (examples of valid types 
are "tcp" and on UNIX "unix")
Received signal 11 SEGV_MAPERR 
#0 0x01bd4b8c 
#1 0x01b6fd58 
#2 0x01bd4e7e 
#3 0x01bd50c0 
#4 0x72c57fe0 
#5 0x00aac948 
#6 0x01e12400 
#7 0x0211e9de 
#8 0x02a5975c 
#9 0x02a59828 
#10 0x02a59902 
#11 0x02a59988 
#12 0x02a599ba 
#13 0x01a9c01c 
#14 0x01a9c052 
#15 0x0197125c 
#16 0x0197a620 
#17 0x0197a88a 
#18 0x00e97312 
#19 0x010b9ed6 
#20 0x00e9e2f2 
#21 0x00e9f13e 
#22 0x00e9f32e 
#23 0x0194c166 
#24 0x0194c264 
#25 0x01951558 
#26 0x0194b572 
#27 0x0091f95c ChromeMain
#28 0x72c494aa __libc_start_main
[end of stack trace]
Calling _exit(1). Core file will not be generated.


~> chromium --debug
# Env:
# LD_LIBRARY_PATH=
#PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.LIy3SY
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 
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 "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...(no debugging symbols 
found)...done.
(gdb) run
Starting program: /usr/lib/chromium/chromium --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x7079f180 (LWP 17925)]
[New Thread 0x6fdff180 (LWP 17930)]
[New Thread 0x6f3ff180 (LWP 17931)]
[New Thread 0x6dffe180 (LWP 17932)]
[New Thread 0x6d5ff180 (LWP 17933)]
[New Thread 0x6cbff180 (LWP 17934)]
[New Thread 0x6c3ff180 (LWP 17935)]
[New Thread 0x6d7fe180 (LWP 17936)]
[17922:17922:0818/152556.062398:ERROR:default_network_context_params.cc(60)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x6baff180 (LWP 17937)]
[New Thread 0x6b2ff180 (LWP 17938)]
[New Thread 0x6aaff180 (LWP 17939)]
[New Thread 0x6a2ff180 (LWP 17940)]
[New Thread 0x69aff180 (LWP 17941)]
[New Thread 0x692ff180 (LWP 17942)]
[New Thread 0x68aff180 (LWP 17943)]
[New Thread 0x682ff180 (LWP 17944)]
[New Thread 0x67aff180 (LWP 17945)]
[New Thread 0x672ff180 (LWP 17946)]
[New Thread 0x66aff180 (LWP 17947)]
[New Thread 0x662ff180 (LWP 17948)]
[New Thread 0x65aff180 (LWP 17949)]
[New Thread 0x652ff180 (LWP 17950)]
[New Thread 0x64aff180 (LWP 17951)]
[New Thread 0x642ff180 (LWP 17952)]
[New Thread 0x60a51180 (LWP 18004)]
[New Thread 0x5fa4c180 (LWP 18005)]
[17922:18005:0818/152559.920026:ERROR:bus.cc(394)] Failed to connect to the 
bus: Could not parse server address: Unknown address type (examples of valid 
types are "tcp" and on UNIX "unix")
[17922:17922:0818/152559.921389:ERROR:default_network_context_params.cc(60)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x5f24c180 (LWP 18006)]
[Thread 0x5f24c180 (LWP 18006) exited]
[New Thread 0x5ea4c180 (LWP 18007)]
[New Thread 0x5e24c180 (LWP 18008)]
[New Thread 0x5da4c180 (LWP 18009)]
[New Thread 0x5d24c180 (LWP 18010)]
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[New Thread 0x5ca4c180 (LWP 18011)]
[New Thread 0x5c24c180 (LWP 18012)]
[New Thread 0x5ba4c180 (LWP 18013)]
[New Thread 0x5b24c180 (LWP 18014)]
[New Thread 0x5aa4c180 (LWP 18015)]
[New Thread 0x5a24c180 (LWP 18016

Bug#906548: chromium: Chromium crashes with SEGV on startup in Stable on RPI

[Patrick Häcker]

Package: chromium
Version: 67.0.3396.87-1~deb9u1
Severity: important

Dear Maintainer,

the version in stable crashes after the security update on a Raspberry Pi
on startup. The system ist mainly Debian stable with some Raspbian packages.
I couldn't find the dbgsym package, so please point me to it. Until then
this is the --debug output:

~> chromium --debug
# Env:
# LD_LIBRARY_PATH=
#PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.LIy3SY
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 
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 "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...(no debugging symbols 
found)...done.
(gdb) run
Starting program: /usr/lib/chromium/chromium --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x7079f180 (LWP 17925)]
[New Thread 0x6fdff180 (LWP 17930)]
[New Thread 0x6f3ff180 (LWP 17931)]
[New Thread 0x6dffe180 (LWP 17932)]
[New Thread 0x6d5ff180 (LWP 17933)]
[New Thread 0x6cbff180 (LWP 17934)]
[New Thread 0x6c3ff180 (LWP 17935)]
[New Thread 0x6d7fe180 (LWP 17936)]
[17922:17922:0818/152556.062398:ERROR:default_network_context_params.cc(60)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x6baff180 (LWP 17937)]
[New Thread 0x6b2ff180 (LWP 17938)]
[New Thread 0x6aaff180 (LWP 17939)]
[New Thread 0x6a2ff180 (LWP 17940)]
[New Thread 0x69aff180 (LWP 17941)]
[New Thread 0x692ff180 (LWP 17942)]
[New Thread 0x68aff180 (LWP 17943)]
[New Thread 0x682ff180 (LWP 17944)]
[New Thread 0x67aff180 (LWP 17945)]
[New Thread 0x672ff180 (LWP 17946)]
[New Thread 0x66aff180 (LWP 17947)]
[New Thread 0x662ff180 (LWP 17948)]
[New Thread 0x65aff180 (LWP 17949)]
[New Thread 0x652ff180 (LWP 17950)]
[New Thread 0x64aff180 (LWP 17951)]
[New Thread 0x642ff180 (LWP 17952)]
[New Thread 0x60a51180 (LWP 18004)]
[New Thread 0x5fa4c180 (LWP 18005)]
[17922:18005:0818/152559.920026:ERROR:bus.cc(394)] Failed to connect to the 
bus: Could not parse server address: Unknown address type (examples of valid 
types are "tcp" and on UNIX "unix")
[17922:17922:0818/152559.921389:ERROR:default_network_context_params.cc(60)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x5f24c180 (LWP 18006)]
[Thread 0x5f24c180 (LWP 18006) exited]
[New Thread 0x5ea4c180 (LWP 18007)]
[New Thread 0x5e24c180 (LWP 18008)]
[New Thread 0x5da4c180 (LWP 18009)]
[New Thread 0x5d24c180 (LWP 18010)]
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[New Thread 0x5ca4c180 (LWP 18011)]
[New Thread 0x5c24c180 (LWP 18012)]
[New Thread 0x5ba4c180 (LWP 18013)]
[New Thread 0x5b24c180 (LWP 18014)]
[New Thread 0x5aa4c180 (LWP 18015)]
[New Thread 0x5a24c180 (LWP 18016)]
[New Thread 0x59a4c180 (LWP 18017)]
[New Thread 0x5924c180 (LWP 18018)]
[Thread 0x5924c180 (LWP 18018) exited]

Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x00a53948 in ?? ()
(gdb) bt
#0  0x00a53948 in ?? ()
#1  0x01db9400 in ?? ()
#2  0x020c59de in ?? ()
#3  0x02a0075c in ?? ()
#4  0x02a00828 in ?? ()
#5  0x02a00902 in ?? ()
#6  0x02a00988 in ?? ()
#7  0x02a009ba in ?? ()
#8  0x01a4301c in ?? ()
#9  0x01a43052 in ?? ()
#10 0x0191825c in ?? ()
#11 0x01921620 in ?? ()
#12 0x0192188a in ?? ()
#13 0x00e3e312 in ?? ()
#14 0x01060ed6 in ?? ()
#15 0x00e452f2 in ?? ()
#16 0x00e4613e in ?? ()
#17 0x00e4632e in ?? ()
#18 0x018f3166 in ?? ()
#19 0x018f3264 in ?? ()
#20 0x018f8558 in ?? ()
#21 0x018f2572 in ?? ()
#22 0x008c695c in ChromeMain ()
#23 0x72d3f4aa in __libc_start_main (main=0x8b088d, argc=8, argv=0x7efff4f4, 
init=, 
fini=0x3bca4c5 <__libc_csu_fini>, rtld_fini=0x76fe2edd <_dl_fini>, 
stack_end=0x7efff4f4) at libc-start.c:291
#24 0x008c67d0 in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Kind regards
Patrick

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.3 (stretch)
Release:9.3
Cod

Bug#891957: netbeans no starting "loading module" modules.netbinox NullPointerException

[Patrick Häcker]

Hi,

> I suspect this is because of the recent update of libequinox-osgi-java.
your suspicion is correct. Downgrading libequinox-osgi-java with
> apt install libequinox-osgi-java/stable
fixes the issue (although it removes eclipse if that is not downgraded as 
well).

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#890547: util-linux: partx fails to read a partition table which fdisk can read

[Patrick Häcker]

Hi,

> See
> https://github.com/yontalcar/util-linux/commit/
> e9ca294aeeec9b32a979024a5f9c23e73325f2b0 
> for patch.

thanks for the fix.
I can confirm, that it works and is more elegant than the version I came up 
with (appended only for the record).

So from my point of view this bug can be closed as soon as the new version 
hits the Debian archive.

Kind regards
Patrick--- util-linux-2.31.1.orig/libblkid/src/partitions/dos.c
+++ util-linux-2.31.1/libblkid/src/partitions/dos.c
@@ -311,8 +311,13 @@ static int probe_dos_pt(blkid_probe pr,
size_t n;
int rc;

-   if (!dos_partition_get_size(p) || is_extended(p))
+   if (!dos_partition_get_size(p) || is_extended(p)) {
+   /* Neutralize increment of i for empty partitions, as p
+* contains all partitions, whereas ls contains only the
+* non-empty ones. */
+   i--;
continue;
+   }

for (n = 0; n < ARRAY_SIZE(dos_nested); n++) {
if (dos_nested[n].type != p->sys_ind)


signature.asc
Description: This is a digitally signed message part.

Bug#890547: Bug localization

[Patrick Häcker]

Hi,

calling partx with the libblkid debug environment variable like
> env LIBBLKID_DEBUG=all partx --show /dev/sda
results in the following:

6729: libblkid: INIT: library debug mask: 0x 
6729: libblkid: INIT: library version: 2.31.1 [19-Dec-2017] 
Available "LIBBLKID_DEBUG=[,...]|" debug masks: 
  all  [0x] : info about all subsystems 
  cache[0x0004] : blkid tags cache 
  config   [0x0008] : config file utils 
  dev  [0x0010] : device utils 
  devname  [0x0020] : /proc/partitions evaluation 
  devno[0x0040] : conversions to device name 
  evaluate [0x0080] : tags resolving 
  help [0x0001] : this help 
  lowprobe [0x0100] : superblock/raids/partitions probing 
  buffer   [0x2000] : low-probing buffers 
  probe[0x0200] : devices verification 
  read [0x0400] : cache parsing 
  save [0x0800] : cache writing 
  tag  [0x1000] : tags utils 
6729: libblkid: LOWPROBE: allocate a new probe 0x556a99d8e2c0 
6729: libblkid: LOWPROBE: zeroize wiper 
6729: libblkid: LOWPROBE: ready for low-probing, offset=0, size=128035676160 
6729: libblkid: LOWPROBE: whole-disk: YES, regfile: NO 
6729: libblkid: LOWPROBE: partlist reset 
6729: libblkid: LOWPROBE: parts: initialized partitions list (0x556a99d8e3d0, 
size=0) 
6729: libblkid: LOWPROBE: --> starting probing loop [PARTS idx=-1] 
6729: libblkid: LOWPROBE:   read 0x556a99d8e438: off=0 len=1024 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid: LOWPROBE:   magic sboff=510, kboff=0 
6729: libblkid: LOWPROBE: dos: ---> call probefunc() 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=512) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid: LOWPROBE:   magic sboff=0, kboff=0 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=512) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=512) 
6729: libblkid: LOWPROBE: parts: create a new partition table (0x556a99d8e840, 
type=dos, offset=446) 
6729: libblkid: LOWPROBE: parts: add partition (0x556a99d8e8a0 start=2048, 
size=62734336, table=0x556a99d8e840) 
6729: libblkid: LOWPROBE: parts: add partition (0x556a99d8e9a0 start=62736384, 
size=141438976, table=0x556a99d8e840) 
6729: libblkid: LOWPROBE: parts: add partition (0x556a99d8eaa0 
start=204175360, size=45893632, table=0x556a99d8e840) 
6729: libblkid: LOWPROBE: parts: > solaris subprobe requested 
(parent=(nil)) 
6729: libblkid: LOWPROBE: partlist reset 
6729: libblkid: LOWPROBE: dos probefunc failed, rc -22 
6729: libblkid: LOWPROBE: dos: <--- (rc = -22) 
6729: libblkid: LOWPROBE: <-- leaving probing loop (failed=-22) [PARTS idx=3] 
6729: libblkid: LOWPROBE: partitions probe done [rc=-22] 
partx: /dev/sda: Partitionstabelle konnte nicht gelesen werden 
6729: libblkid:   BUFFER: Resetting probing buffers pr=0x556a99d8e2c0 
6729: libblkid:   BUFFER:  remove buffer: 0x556a99d8e438 [off=0, len=1024] 
6729: libblkid: LOWPROBE:  buffers summary: 1024 bytes by 1 read() calls 
6729: libblkid: LOWPROBE: free probe 0x556a99d8e2c0


There, the Solaris subprobe request fails (swap and Solaris partitions both 
seems to share the same partition type byte 0x82), which leads to the failing 
of partx.

The problem originates in dos.c:probe_dos_pt where
> p0 = mbr_get_partition(data, 0);
returns an array of length 4 with the second partition contains only 0 values 
as the partition is not used. Thus, the fourth partition (index 3) is a valid 
swap partition. However,
> ls = blkid_probe_get_partlist(pr);
returns an array of length 3 within ls->parts where only the non-empty 
partitions are listed and thus the swap partition is the third partition 
(index 2).

In the subtypes parsing block towards the end of the dos.c:probe_dos_pt 
function the code combines these logically non-aligned arrays with
> rc = blkid_partitions_do_subprobe(pr,
> blkid_partlist_get_partition(ls, i),
> dos_nested[n].id);
for i=3 which results in a NULL pointer from blkid_partlist_get_partition, 
which itself results into -EINVAL in blkid_partitions_do_subprobe as parent is 
NULL.

To be clear: The tru

Bug#890547: util-linux: partx fails to read a partition table which fdisk can read

[Patrick Häcker]

Appending the MBR for replicating the problem, using
> fdisk -l MBR
or
> partx --show MBR

Regards
Patrick

MBR
Description: Binary data

Bug#890547: util-linux: partx fails to read a partition table which fdisk can read

[Patrick Häcker]

Package: util-linux
Version: 2.31.1-0.4
Severity: normal

Dear Maintainer,

the command
> partx --show /dev/sda
prints
> partx: /dev/sda: failed to read partition table

However,
> fdisk -l /dev/sda
results in
> Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x0006f804
> 
> Device Boot Start   End   Sectors  Size Id Type
> /dev/sda12048  62736383  62734336 29,9G 83 Linux
> /dev/sda362736384 204175359 141438976 67,5G 83 Linux
> /dev/sda4   204175360 250068991  45893632 21,9G 82 Linux swap / Solaris

The partition table seems to be completely valid according to fdisk. There
are no problems by using the disk's partitions. The partitions have probably
been created with cfdisk and changed with gparted, where the second partition
has been deleted.

The relevant part of a hexdump of this disk:
> 1b0 10cd 3cac 7500 c3f4 f804 0006  2000
> 1c0 0021 fe83  0800  4000 03bd 
> 1d0        fe00
> 1e0  fe83  4800 03bd 3000 086e fe00
> 1f0  fe82  7800 0c2b 4800 02bc aa55

Due to usage of little endianness, this looks correct according to
> https://de.wikipedia.org/wiki/Master_Boot_Record#Aufbau_der_Partitionstabelle
(sorry, in German, but great figure) or
> https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries

Even if it were wrong, fdisk and partx should have identical results.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug'), (400, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-rc8-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages util-linux depends on:
ii  fdisk  2.30.2-0.3
ii  libblkid1  2.31.1-0.1
ii  libc6  2.26-6
ii  libmount1  2.30.2-0.3
ii  libpam0g   1.1.8-3.7
ii  libselinux12.7-2+b1
ii  libsmartcols1  2.30.2-0.3
ii  libsystemd0236-3
ii  libtinfo5  6.0+20171125-1
ii  libudev1   236-3
ii  libuuid1   2.30.2-0.3
ii  zlib1g 1:1.2.8.dfsg-5

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-1
ii  kbd 2.0.4-2
pn  util-linux-locales  

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:

Bug#769325: mediatomb: Mediatomb does not work with systemd

[Patrick Häcker]

Hi James,

thanks for taking care of Gerbera and mediatomb's bug reports.

Unfortunately, I do not have a UPnP setup anymore, so I can't test it. 
However, with /etc/default being removed, I can't see how this bug could still 
occur, so even without testing, I am very positive, that the bug is fixed.

Thanks
Patrick

On Sat, 25 Nov 2017 06:35:00 + James Cowgill  wrote:
> Source: gerbera
> Source-Version: 1.0.0-1
> 
> Hi,
> 
> I think this bug is fixed in gerbera. The gerbera package has a much
> simpler systemd service file (all it does is invoke the main program)
> and the /etc/default file has been removed so all configuration is read
> from config.xml now.
> 
> It would be good if you could test it and reply if there is still a problem.
> 
> Thanks,
> James
> 


signature.asc
Description: This is a digitally signed message part.

Bug#849107: consolation: Inconsistent naming of pointer acceleration speed

[Patrick Häcker]

On Sun, 25 Dec 2016 14:23:30 +0100 Bill Allombert  wrote:
> On Thu, Dec 22, 2016 at 06:44:42PM +0100, Patrick Häcker wrote:
> > Package: consolation
> > Version: 0.0.4-1
> > Severity: minor
> > Tags: patch

> > the pointer acceleration speed option is named as "--set-speed="
> > when entering "--help" and in the man page. Albeit, the program searches
> > for the variable named "--speed". Please correct either the documentation
> > or the argument parsing code.
> > 
> > When you are at it: It would be nice to add to the documentation that
> > smaller values lead to faster cursor movement.

Hello Bill

> Actually this a bug in libinput source code that is used as reference
> for consolation.
> /usr/bin/libinput-debug-events --help
> in the package libinput-tools has exactly the same issue.
okay, thanks. Both  "--set-speed" versus "--speed" and the misleading name are 
basically copied from the libinput-tools package.  As I assume, consolation 
should stay in sync with libinput-tools, can you duplicate this bug and have 
the duplicate point to package libinput-tools? Then both packages could be 
fixed and still be kept in sync.

> It seems you forgot to attach the patch.
The tag was meant as: Instructions how to solve this bug are included and 
probably not more work than applying a patch. Sorry if this lead to confusion.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#849107: consolation: Inconsistent naming of pointer acceleration speed

[Patrick Häcker]

Package: consolation
Version: 0.0.4-1
Severity: minor
Tags: patch

Dear Maintainer,

the pointer acceleration speed option is named as "--set-speed=" when
entering "--help" and in the man page. Albeit, the program searches for the
variable named "--speed". Please correct either the documentation or the
argument parsing code.

When you are at it: It would be nice to add to the documentation that smaller
values lead to faster cursor movement. This is a bit suprising for a value
named "speed" as it behaves more like a threshold than like speed.

Thanks for the useful program.

Kind regards
Patrick

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 'unstable-debug'), (400, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 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 consolation depends on:
ii  libc6   2.24-8
ii  libevdev2   1.5.5+dfsg-1
ii  libinput10  1.5.3-1
ii  libudev1232-7
ii  lsb-base9.20161125

consolation recommends no packages.

consolation suggests no packages.

-- Configuration Files:
/etc/default/consolation changed [not included]

-- no debconf information

Bug#617856: apt-show-versions: does not see gzipped Packages files when uncompressed are not available

[Patrick Häcker]

I looked a bit into the problem in version 0.22.7 and found the following via 
perl -d:

In line 198, the directory /var/lib/apt/lists (the content of $list_dir)  is 
searched for files _ending_ with "Packages" (note the dollar sign after 
Packages):
> files = map { $list_dir . $_} grep /Packages$/, readdir(DIR);

So none of the compression formats which can be used by setting apt.conf' 
GzipIndexes option (ending with at least "Packages.gz" and "Packages.lz4", but 
probably more) are supported by apt-show-versions. You can of course change 
this line and remove the dollar sign after Packages, but this won't do it 
because of the following.

In line 564 (in function parse_file), the Package file is parsed. 
Unfortunately, 
this is done by reading it as a normal text file line by line (see line 566), 
which cannot work with compressed files, even if the above fix has been 
applied. 

You could try to decompress, depending on the file extension, with a suitable 
perl library, but all I found in Debian for lz4 (my itch and in the future 
probably most people's itch) by a quick search was a library which would 
decompress the whole file at once, so you would first need to load the whole 
file 
and then decompress it. As the file can be several megabytes large, this is not 
the best approach, although it would be doable.

Alternatively, you could depend on all packages like liblz4-tool and read the 
file through a pipe. This would be possible, but this would install some 
packages, which would not be used at all (because you would have to depend on 
every compression format supported by apt, even if not currently used).

After having a look on apt-show-versions, I think that its approach is flawed. 
apt already provides tools to read the database, which are performance-
optimized (at least in the most recent versions) and support all compression 
formats. Maybe I am overlooking something, but in my opinion, apt-show-
versions should be changed from reading the packages files and maintaining its 
own cache to parsing apt-cache's output. That said, I am not going to provide 
a patch for that, as I just switched with my main apt-show-versions use-case 
to apt.

So instead of
> apt-show-versions -a $PACKAGENAME
I switched to use
> apt policy $PACKAGENAME.

Although I like apt-show-versions' output more, this way the query is so much 
faster. Additionally, I can activate options like GzipIndexes accelerating apt 
also for other use-cases  without getting problems. And after purging apt-
show-versions, I do not get these any longer:
> Error: No information about packages! (Maybe no deb entries?)
> E: Problem executing scripts APT::Update::Post-Invoke-Success 'test -x 
/usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i'
> E: Sub-process returned an error code

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#810588: muon-updater: Changelog is not shown

[Patrick Häcker]

Package: muon-updater
Version: 4:5.4.3-1
Severity: normal

Dear Maintainer,

when selecting a package in the Muon Update Manager, I always get the text
"The list of changes is not yet available.",
instead of the expected changelog delta.

Kind regards
Patrick

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 'unstable-debug'), (400, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 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 muon-updater depends on:
ii  libc6 2.21-6
ii  libkf5configwidgets5  5.16.0-1
ii  libkf5coreaddons5 5.16.0-1
ii  libkf5dbusaddons5 5.16.0-1
ii  libkf5i18n5   5.16.0-1
ii  libkf5iconthemes5 5.16.0-1
ii  libkf5widgetsaddons5  5.16.0-1
ii  libkf5xmlgui5 5.16.0-1
ii  libmuon   4:5.4.3-1
ii  libqapt3-runtime  3.0.1-1+b1
ii  libqt5core5a  5.5.1+dfsg-10
ii  libqt5gui55.5.1+dfsg-10
ii  libqt5widgets55.5.1+dfsg-10
ii  libstdc++65.3.1-5

Versions of packages muon-updater recommends:
ii  muon-notifier  4:5.4.3-1

muon-updater suggests no packages.

-- no debconf information

Bug#810124: digikam: Does not show albums until kbuildsycoca is manually called

[Patrick Häcker]

Package: digikam
Version: 4:4.14.0-3
Severity: important
Tags: patch

Dear Maintainer,

after installing digikam, no existing albums could be viewed. The error
message was:

Couldn't create slave: "Unable to create io-slave:
klauncher said: Unknown protocol: digikamdates

After calling
kbuildsycoca4 --noincremental
and
kbuildsycoca5 --noincremental
everything worked as expected. I didn't test it, but I assume, that the
latter command has been unnecessary, as digikamdates.protocol is located
in the KDE4 directory (/usr/share/kde4/services/).

So please call
kbuildsycoca4 --noincremental
after normal package installation (as it is done in other Debian KDE packages,
although I do not know how it is done exactly).

Kind regards
Patrick


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 'unstable-debug'), (400, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 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 digikam depends on:
ii  digikam-data4:4.14.0-3
ii  digikam-private-libs4:4.14.0-3
ii  kde-runtime 4:15.08.3-1
ii  libc6   2.21-6
ii  libgcc1 1:5.3.1-4
ii  libgphoto2-62.5.9-3
ii  libgphoto2-port12   2.5.9-3
ii  libkdcraw23 4:15.08.0-1+b1
ii  libkdecore5 4:4.14.14-1+b1
ii  libkdeui5   4:4.14.14-1+b1
ii  libkexiv2-114:15.04.3-1
ii  libkhtml5   4:4.14.14-1+b1
ii  libkio5 4:4.14.14-1+b1
ii  libkipi11   4:15.08.3-1
ii  libknotifyconfig4   4:4.14.14-1+b1
ii  libkparts4  4:4.14.14-1+b1
ii  libopencv-core2.4v5 2.4.9.1+dfsg-1.2
ii  libopencv-imgproc2.4v5  2.4.9.1+dfsg-1.2
ii  libphonon4  4:4.8.3-2
ii  libqt4-dbus 4:4.8.7+dfsg-5
ii  libqt4-sql  4:4.8.7+dfsg-5
ii  libqt4-sql-sqlite   4:4.8.7+dfsg-5
ii  libqt4-xml  4:4.8.7+dfsg-5
ii  libqtcore4  4:4.8.7+dfsg-5
ii  libqtgui4   4:4.8.7+dfsg-5
ii  libsolid4   4:4.14.14-1+b1
ii  libstdc++6  5.3.1-4
ii  libthreadweaver44:4.14.14-1+b1
ii  perl5.22.1-3
ii  phonon  4:4.8.3-2

Versions of packages digikam recommends:
ii  chromium [www-browser]   46.0.2490.71-1
ii  iceweasel [www-browser]  43.0.2-1+b1
ii  kipi-plugins 4:4.14.0-3
ii  konqueror [www-browser]  4:15.08.3-1
ii  mplayerthumbs4:15.08.3-1
ii  w3m [www-browser]0.5.3-26

Versions of packages digikam suggests:
pn  digikam-doc 
ii  systemsettings  4:5.4.3-1

-- no debconf information

Bug#776202: skrooge: Please package version 1.10.91

[Patrick Häcker]

I just found out, that 1.10.91 is a development version, so packaging 1.10.0 
might be more appropriate, though either of both versions would be fine in 
experimental, I think.

Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#776202: skrooge: Please package version 1.10.91

[Patrick Häcker]

Package: skrooge
Version: 1.9.3-1
Severity: wishlist

Dear Maintainer,

version 1.10.0 is available for three months now. In the mean time, version
1.10.91 became available. It would be great, if you could package it.
To do not disrupt Jessie, an upload to experimental might be the best option.
Thus, after the release of Jessie, 1.10.91 could directly be uploaded to
unstable.

Kind regards
Patrick

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/6 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 skrooge depends on:
ii  kde-runtime  4:4.14.2-2
ii  kdepim-runtime   4:4.14.2-3
ii  libakonadi-kde4  4:4.14.2-2+b1
ii  libc62.19-13
ii  libgcc1  1:4.9.1-19
ii  libgrantlee-core00.4.0-2
ii  libkactivities6  4:4.13.3-1
ii  libkcalcore4 4:4.14.2-2+b1
ii  libkdecore5  4:4.14.2-4
ii  libkdeui54:4.14.2-4
ii  libkio5  4:4.14.2-4
ii  libknewstuff3-4  4:4.14.2-4
ii  libknotifyconfig44:4.14.2-4
ii  libkparts4   4:4.14.2-4
ii  libkrosscore44:4.14.2-4
ii  libnepomuk4  4:4.14.2-4
ii  libnepomukutils4 4:4.14.2-4
ii  libofx6  1:0.9.10-1
ii  libplasma3   4:4.14.2-4
ii  libqca2  2.0.3-6
ii  libqca2-plugin-ossl  2.0.0~beta3-2
ii  libqjson00.8.1-3
ii  libqt4-dbus  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-network   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-script4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-sql   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-sql-sqlite4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-svg   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-xml   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtcore4   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtgui44:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtwebkit4 2.3.4.dfsg-3
ii  libsoprano4  2.9.4+dfsg-1.1
ii  libsqlite3-0 3.8.7.1-1
ii  libstdc++6   4.9.1-19
ii  skrooge-common   1.9.3-1

skrooge recommends no packages.

skrooge suggests no packages.

-- no debconf information


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

Bug#772884: abtransfers: AB-Transfer's menu entry does not have an icon

[Patrick Häcker]

Hi Tobias,

On Fri, 02 Jan 2015 16:15:27  0100 Tobias Scherer  wrote:
> I altered the package according to Patricks proposal.
> Please find attached the diff-file.

thank you very much for implementing this. Such small little details really 
make a difference.

Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#744753: Fix for anacron (running on resume under systemd)

[Patrick Häcker]

Hi Michael,

> That means, depending on the timing, anacron-resume.service might be
> triggered just before suspend not on resume, and it's not guaranteed
> that anacron has finished before systemd-sleep is called.
> 
> I don't think the patch was intended this way?
thanks for the analysis. Is there are reason for not reopening the bug?

Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#769325: mediatomb: Mediatomb does not work with systemd

[Patrick Häcker]

Dear Héctor,

sorry for the delay until I found the time to answer.

> > So this is definitely inconsistent (using the port number from
> > /etc/default/mediatomb in systemd and using the port number from
> > /etc/mediatomb/config.xml in the init script) and completely
> > non-transparent to the user.
> 
> For reference, Fedora which did the systemd units ships with:
>   http://pkgs.fedoraproject.org/cgit/mediatomb.git/tree/mediatomb.service
> 
> So, IIUC, you suggest to release mediatomb without a preconfigured
> port because it causes conflicts when user has those settings
> configured in config.xml file. I might need to do some testing on that
> before pushing it forward.
I probably didn't think about that, but it sounds like a good idea, to either 
add the port to the sysvinit script, or to remove it from the systemd call. 
This would lead to a consistent Mediatomb behavior when switching the init 
system. Currently, Mediatomb can break when switching from sysvinit to 
systemd. The latter solution has the advantage, that there can be no 
conflicting port definition between the configurations in 
/etc/default/mediatomb and /etc/mediatomb/config.xml.

> > The reason can be seen in
> > /var/log/mediatomb:
> > ERROR: You can not specify interface and IP at the same time!
> > (Remember, that the ip has been set in /etc/mediatomb/config.xml)
> 
> Same conflict between config.xml and daemon configuration.

> I agree with your analysis, adding a NEWS note might be consistent.
 
> Let's focus on Jessie release, we need to do minimal, less intrusive
> changes to be able to pass release team acceptance.
> My plan is to drop MT_PORT and MT_INTERFACE from systemd unit file, if
> that works for all of us.
Unfortunately, I think that does not work in all cases. With your proposed 
change if a user configured the interface in /etc/default/mediatomb, his 
configuration changes by switching from sysvinit to systemd, as his 
configuration option is loaded from /etc/init.d/mediatomb, but not from 
/lib/systemd/system/mediatomb.service.

I think it will not even work with the port in all cases, as if a testing or 
unstable user configured the port in /etc/default/mediatomb and used systemd, 
his port has been respected before this change, but will not anymore after 
this change. But I think this is acceptable if accompanied with a NEWS note, 
as testing and unstable user should be able to cope with that and the behavior 
has not been in the archive for long.

> > I recommend to patch Mediatomb to exit with an error if the interface (and
> > ip) is configured in both /etc/mediatomb/config.xml and
> > /etc/default/mediatomb with differing values.

> For next release, are you willing to work/propose a patch that exits
> gratefully when there is a config mismatch between config.xml and
> default config? I would be willing to support that idea.
> 
> Do you think that is good compromise?
Yes, I really appreciate your patient and impressive handling of this bug 
report. However, I think my proposal is flawed. If Mediatomb checks, if 
/etc/init.d/mediatomb and /etc/mediatomb/config.xml contain conflicting 
variables, Mediatomb will also warn, if it has not been started by the init 
script or the unit file at all, which is wrong, because then there is no 
conflict. Depending on the implementation it will even warn, if 
/etc/mediatomb/config.xml is not used at all.

Fortunately, the proposal can be fixed, for example if Mediatomb detects how 
it has been started (by init script or by unit file or independently). 
However, this sounds like a hard problem.

Alternatively, the init script or the unit file have to do the checks, because 
they have all the information they need. I do not know if systemd can handle 
such a setup, but I guess, that it can execute some shell code, too.

Surprisingly, if we only want to support the default situation (where no 
variables have been removed from /etc/default/mediatomb), it's very simple to 
check if there are options in /etc/mediatomb/config.xml which will be ignored, 
as the options are already set in /etc/default/mediatomb:

> egrep --quiet '|' $MT_HOME/$MT_CFGDIR/config.xml \
> && echo "Warning:  or  definition in \
> $MT_HOME/$MT_CFGDIR/config.xml will be ignored \
> and the values defined in /etc/default/mediatomb will be used instead"

This check could easily be extended to test for , too. Do you think this 
would work?

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#744753: anacron: Anacron not triggered when system resumes under systemd

[Patrick Häcker]

> Of course, my proposed patches would requires that the machine is
> turned on at xx:00 at least once a day.
Although that patch is much better than the current behavior, I don't think 
that the solution is general enough.

It's perfectly legitimate to use a device only for some minutes every time 
it's powered on. And it's probably not that uncommon for such devices that 
they are used at a regular time, e.g. after work or something like that. This 
time frame might contain a xx:00 or not. As anacron performs jobs like backups 
and installing security updates, it's unacceptable, that it's pure luck (from 
a user's point of view) whether anacron runs or not.

Thus, either a resume hook or changing anacron from a one-shot program to a 
daemon is needed. When using init.d the decision was to use a hook, so it 
would probably make sense to do the same with systemd.

Kind regards
Patrick


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

Bug#568008: Error inserting padlock_sha: No such device

[Patrick Häcker]

Dear maintainer,

I reopened this bug, as I think that there is a regression in current 
versions, because the observed behavior is the same as in this bug report (and 
in #485070), i.e. there is an alarming message on boot without showing a 
problem otherwise. I think the problem is well described in #107.

This is the relevant journal output:
> systemd-modules-load[153]: Inserted module 'dm_crypt'
> systemd-modules-load[153]: Inserted module 'aes_i586'
> systemd-modules-load[153]: Failed to insert 'aesni_intel': No such device
> systemd-modules-load[153]: Failed to insert 'padlock_aes': No such device
> systemd[1]: systemd-modules-load.service: main process exited, code=exited, 
status=1/FAILURE
> systemd[1]: Failed to start Load Kernel Modules.
> systemd[1]: Unit systemd-modules-load.service entered failed state.

This is the alias:
> # modprobe --resolve-alias aes
> aes_i586
> aesni_intel
> padlock_aes

So I guess, that -- as desribed in #107 -- loading of the alias aes is 
requested. But although aes_i586 can be loaded (verified with lsmod), modprobe 
seems to return 1 leading to the error messages above and the failure of the 
service (verified with fish shell, so $status is bash's $?):
> # modprobe --verbose aes; echo $status
> insmod /lib/modules/3.16.0-4-686-pae/kernel/arch/x86/crypto/aesni-intel.ko 
> modprobe: ERROR: could not insert 'aesni_intel': No such device
> insmod /lib/modules/3.16.0-4-686-pae/kernel/drivers/crypto/padlock-aes.ko 
> modprobe: ERROR: could not insert 'padlock_aes': No such device
> 1

modprobe is part of the kmod package, which is installed in version 18-3.

Kind regards
Patrick


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

Bug#772884: abtransfers: AB-Transfer's menu entry does not have an icon

[Patrick Häcker]

Package: abtransfers
Version: 0.0.5.0-2
Severity: minor
Tags: patch

Dear Maintainer,

I've seen the patch for adding a menu entry for AB-Transfers. Thanks a lot
for that (thanks to Tobias Scherer, too).

I suggest to also add an icon by using the following content for
/usr/share/applications/abtransfers.desktop:

[Desktop Entry]
Name=AB-Transfers
Categories=Office
Exec=abtransfers
Terminal=false
Type=Application
Icon=/usr/share/abtransfers/bank_transfer_128x128.png
GenericName[de]=Banküberweisung

This requires to add the file images/bank_transfer_128x128.png from the
source directory to /usr/share/abtransfers/bank_transfer_128x128.png.
I also changed the Name to match the name in the program's title bar.
Additionally, I added a German translation for the generic name.

Kind regards
Patrick

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/6 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 abtransfers depends on:
ii  libaqbanking34  5.4.3beta-2+b1
ii  libaqbanking34-plugins  5.4.3beta-2+b1
ii  libc6   2.19-13
ii  libgcc1 1:4.9.1-19
ii  libgwengui-cpp0 4.12.0beta-3+b1
ii  libgwengui-qt4-04.12.0beta-3+b1
ii  libgwenhywfar60 4.12.0beta-3+b1
ii  libqtcore4  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtgui4   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libstdc++6  4.9.1-19

abtransfers recommends no packages.

abtransfers suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/applications/abtransfers.desktop (from 
abtransfers package)


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

Bug#701680: Segfault when attempting to read a file

[Patrick Häcker]

If anyone could tell me how to build djmount with debug information (a simple 
./configure; make does not work, see #772630 for the details), I think I can 
produce a more useful stack trace.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#701680: (no subject)

[Patrick Häcker]

severity 701680 grave
tag 701680 - moreinfo unreproducible
thanks

signature.asc
Description: This is a digitally signed message part.

Bug#772630: closed by Andrey Rahmatullin (Re: Bug#772630: obsolete libupnp?)

[Patrick Häcker]

> Issue is a false positive then, as Dario said. I've build package on my
> machine (Debian Jessie, amd64).

Yes, thanks for the information.

Executing
> apt-get -b source djmount
in a newly created directory works indeed, while
> apt-get source djmount
> cd djmount-0.71
> ./configure
> make
> cd ..
> apt-get source -b djmount
does not work. But I suppose the latter one is not required to work.

Thanks for everybody's help.

Regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#769325: mediatomb: Mediatomb does not work with systemd

[Patrick Häcker]

Hello,

thanks for answering this bug report and sorry for reporting back this late.

> > Even if it started, it wouldn't work, as it does not read the
> > configuration file /etc/mediatomb/config.xml
> > 
> > Additionally, it does not seem to make sense to have
> > /etc/default/mediatomb, as nearly all options are duplicates of options in
> > /etc/mediatomb/config.xml. It is completely unclear to a normal user which
> > value is used, if the values of both files differ.
> /etc/default/mediatomb is a file for daemon configuration (network card to
> attach to, user/group to run under, location of config.xml, etc...)), while
> /etc/mediatomb/config.xml is for mediatomb configuration (see upstream
> documentation http://mediatomb.cc/pages/documentation#id2856319).
Just for clarity for other readers, as I misunderstood this paragraph on first 
read: The documentation does not mention any separation of a "daemon 
configuration" from a "mediatomb documentation". But it states, that all 
relevant network related options are optional in config.xml.

> You are right and some optional values can be set at config.xml, but Debian
> mediatomb older releases have been configuring the daemon, even other
> distros, as Fedora, configure the daemon. It is not our fault the upstream
> provides two different ways to configure the daemon, via CLI or via
> config.xml.
It's absolutely standard for a Unix daemon to be configurable via 
configuration file, environment variables and CLI options (with increasing 
priority in case an option is set multiple times). Nevertheless, I can't 
remember a daemon where the configuration file is not the reference for 
default daemon startup. /etc/default is normally only used with parameters, 
which are not part of the daemon's configuration file.

> > Mediatomb had working systemd support before these changes had been
> > applied.
> Sorry, there was no systemd unit file before, you might had been using the
> old init script which also sets up the daemon.
Thanks for clarification. That's what I meant, but my statement has indeed 
been ambiguous.

> We picked to configure it via CLI with environment file, it has been that
> way for several releases now.
Yes, but in the init-script, config.xml is used (line 80), while in the new 
systemd unit file, config.xml is not used. Or that's what I thought. According 
to the documentation, /etc/mediatomb/config.xml should not be used with the 
configuration used in /lib/systemd/system/mediatomb.service, but I just found 
out, that this is incorrect. The above config.xml file is read even if no "-c" 
option is given in the service file. This makes one problem less.

> > ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P
> > /run/mediatomb.pid
> 
> I do not think it's good idea to run the daemon as root, but instead
> use the mediatomb user/group.
Yes, that was a dumb idea from me, thanks for paying attention. This was the 
minimal working configuration for me and should not be used in Jessie.

> Sorry, I disagree to do those changes at this stage in the release, we are
> frozen.
Yes, we should aim for the least disruptive change which works for everyone. 
But please note, that the change in 0.12.1-7, uploaded directly before the 
freeze, was already a disruptive change, at least to me.

> Also you seem to drop network settings for UPnP to work properly on some
> systems, why is that?
I dropped them as I didn't need them (for a minimal working example). What do 
they do? Are there different UPNP standards and do some devices need them?

> I do not agree on the severity reported, as the package works for me with
> that setup, and it might work for you, if you configure it properly.
> Therefore I am downgrading severity to at most important as I do not think
> it should be removed from jessie release, but I am further interested to
> hear about your proposed changes and find a common area that works for all.
It is not my intention to remove Mediatomb from Jessie. Instead I want to have 
a fix applied to Mediatomb before Jessie is released, as at least two users 
have problems with this version, although they had a working setup before and 
I fear that a lot of users might be affected when Jessie is released. Having 
it documented (with a release critical bug), that this package needs a fix 
before Jessie can be released seemed helpful to me.

Anyway, let's find the root cause, then we have better data and don't have to 
guess so much.
I tried several combination in /lib/systemd/system/mediatomb.service:

# Does not work
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -e $MT_INTERFACE

# Does not work
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT

# Works
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR

So setting the 

Bug#772630: djmount fails to build from source

[Patrick Häcker]

Package: djmount
Version: 0.71-6
Severity: serious
Justification: Policy 4.9 (Package does not successfully run build)

Dear Maintainer,

djmount FTBFS on Jessie (amd64) during linking. The last warning before the 
error:

fuse_main.c: In function ‘main’:
fuse_main.c:621:2: warning: implicit declaration of function 
‘UpnpSetLogFileNames’ [-Wimplicit-function-declaration]
  UpnpSetLogFileNames ("/dev/null", "/dev/null");

The error:

/usr/bin/ld: log.o: relocation R_X86_64_32 against `.bss' can not be used when 
making a shared object; recompile with -fPIC
log.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:477: recipe for target 'djmount' failed

Kind regards
Patrick

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/6 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 djmount depends on:
ii  fuse2.9.3-15+b1
ii  libc6   2.19-13
ii  libfuse22.9.3-15+b1
ii  libtalloc2  2.1.1-2
ii  libupnp61:1.6.19+git20141001-1

djmount recommends no packages.

djmount suggests no packages.

-- no debconf information


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

Bug#769325: mediatomb: Mediatomb does not work with systemd

[Patrick Häcker]

Package: mediatomb
Version: 0.12.1-7
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

version 0.12.1-7 does not start when using systemd without a useable error
message:
> Process: 2788 ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P 
> /run/mediatomb.pid -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -e 
> $MT_INTERFACE (code=exited, status=0/SUCCESS)
> Process: 2785 ExecStartPre=/sbin/ifconfig $MT_INTERFACE allmulti 
> (code=exited, status=0/SUCCESS)
> Process: 2782 ExecStartPre=/sbin/route add -net 239.0.0.0 netmask 255.0.0.0 
> $MT_INTERFACE (code=exited, status=0/SUCCESS)
> Process: 2779 ExecStartPre=/bin/grep -q MT_USER /etc/default/mediatomb 
> (code=exited, status=0/SUCCESS)
> Main PID: 2789 (code=exited, status=1/FAILURE)

Even if it started, it wouldn't work, as it does not read the configuration
file /etc/mediatomb/config.xml, which can be seen in
/lib/systemd/system/mediatomb.service:
> ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P 
> /run/mediatomb.pid -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -e 
> $MT_INTERFACE

Additionally, it does not seem to make sense to have /etc/default/mediatomb,
as nearly all options are duplicates of options in
/etc/mediatomb/config.xml. It is completely unclear to a normal user which
value is used, if the values of both files differ.

Mediatomb had working systemd support before these changes had been applied.
These changes should thus probably be reverted. Alternatively,
/etc/default/mediatomb should be deleted and
/lib/systemd/system/mediatomb.service should be changed into
> [Unit]
> Description=UPnP MediaServer
> After=NetworkManager-wait-online.service network.target
> 
> [Service]
> Type=forking
> PIDFile=/run/mediatomb.pid
> ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P 
> /run/mediatomb.pid
> 
> [Install]
> WantedBy=multi-user.target

Kind regards
Patrick


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages mediatomb depends on:
ii  chromium [www-browser]   38.0.2125.101-3
ii  iceweasel [www-browser]  31.2.0esr-3
ii  konqueror [www-browser]  4:4.14.2-1
ii  mediatomb-daemon 0.12.1-7
ii  rekonq [www-browser] 2.4.2-0ubuntu2
ii  w3m [www-browser]0.5.3-19

mediatomb recommends no packages.

mediatomb suggests no packages.

-- no debconf information


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

Bug#768299: grub2-common: Showing hidden Grub menu with Shift does not work

[Patrick Häcker]

Package: grub2-common
Version: 2.02~beta2-15
Severity: normal

Dear Maintainer,

normally it's possible with Grub to use
> GRUB_TIMEOUT=0
> GRUB_HIDDEN_TIMEOUT=0
in /etc/default/grub to have Grub hidden during normal boots with the
default boot entry being selected immediately. To my knowledge this is
also the fastest way to boot with Grub.

If you really want to select or modify some entry you can hold the shift
key while booting. Then, the menu is shown and the counter stopped.

Since some time (might be months, might be days) the shift key does not
work anymore in testing. This is an important problem if your system does
not boot anymore due to linux command line settings, which cannot be
changed, as the Grub entry cannot be modified, which could be solved with
a downloaded rescue disk, which cannot be downloaded as this is the
system providing the internet connection ...

As a workaround I set GRUB_TIMEOUT to 1 and commented GRUB_HIDDEN_TIMEOUT.
But this does increase boot time and boot flicker, so is probably not the
recommended way for Jessie.

I think I could bisect the Debian Grub packages if that would be helpful.

Kind regards
Patrick

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages grub2-common depends on:
ii  dpkg1.17.21
ii  grub-common 2.02~beta2-15
ii  install-info5.2.0.dfsg.1-5
ii  libc6   2.19-12
ii  libdevmapper1.02.1  2:1.02.90-2
ii  liblzma55.1.1alpha+20120614-2

grub2-common recommends no packages.

grub2-common suggests no packages.

-- no debconf information


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

Bug#764798: RE: Bug#764798: grub2: Grub rescue shell with RAID 6 mdadm over 8 disks

[Patrick Häcker]

On Thu, 23 Oct 2014 18:20:00 -0500 "Mike"  wrote:
> Greetings, anything else needed from me?
> 
> Thanks.

This is complete guessing, but could the file, util/deviceiter.c, i.e. the 
iteration over devices, have something to do with it? In version 
grub2-2.02~beta2, there is this block beginning in line 713 (inside of an 
#ifdef __linux__):
>   /* ATARAID disks.  */
>   for (i = 0; i < 8; i++)
> {
>   [...]
> }

Interestingly, there is a similar block starting in line 645
>   /* IDE disks.  */
>   for (i = 0; i < 96; i++)
> {
>   [...]
> }
which might explain why this problem has not been detected/fixed beforehand. 
There weren't probably a lot of users with more than 96 IDE disks …

This can be completely wrong, but if you already have a test setup, you might 
get the package ("apt-get build-dep grub2; apt-get source grub2") change the 
value, rebuild the package ("fakeroot dpkg-buildpackage -b -uc -us" should 
work), install (dpkg -i ...) and test it.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#677161: grub2-common: update-grub seems not to be run at upgrade from 1.99-14 to 1.99-21

[Patrick Häcker]

> When I then rebooted my computer after an update of grub, I could still
> select the correct kernel in the grub menu at boot, but then grub gave an
> error (partition not found or similar).
Could you please check if the device your firmware (BIOS/EFI/…) boots from is 
really selected in the list shown by "dpkg-reconfigure grub-pc"?

I had a similar behavior (unreliable grub updates with problems every year or 
so) and the root cause was that I had Grub installed on the device the 
firmware executed, but Grub updated its installation on the other drive. So 
whenever there was some major Grub update (I do not know the details), I had 
so manually install (update) grub to my main device.
I was surprised, that I hadn't noticed this before, but from experience I can 
tell that it can take quite some time to notice this.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#767359: fixed in lightdm 1.10.3-3

[Patrick Häcker]

Thanks for fixing that bug.

I just wanted to add, that version 1.10.3-3 also fixes the bug that the 
selected user is not remembered anymore (I was just going to report that 
one). So if anyone wonders how to get rid of that bug, just install 1.10.3-3.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#768087: unattended-upgrade does not fully respect APT priorities

[Patrick Häcker]

Package: unattended-upgrade
Version: 0.83
Severity: normal

Dear Maintainer,

with /etc/apt/apt.conf.d/50unattended-upgrades containing
> Unattended-Upgrade::Origins-Pattern {
> "origin=*";
> };

and /etc/apt/preferences containing
> Package: *
> Pin: release o=Debian,a=stable
> Pin-Priority: 950
> 
> Package: *
> Pin: release o=Debian,a=testing
> Pin-Priority: 900
> 
> Package: *
> Pin: release o=Debian,a=unstable
> Pin-Priority: 400

unattended-upgrade upgrades the packages to unstable if both a testing and
an unstable version exists. This is in contrast to apt-get, which prefers
the testing version in this case.

If no unstable repositories are defined in /etc/apt/sources.list,
unattended-upgrade correctly installs the testing versions.

It's hard to follow the exact defintion of APT's priorities defined in
the man page of apt_preferences. But independent of the correct
interpretation of these definitions, IMHO the only sane way is:
Do the same as apt-get does.
(Thus, I even think that the Origins-Pattern above should be the default,
but let's discuss this some other time.)

Kind regards
Patrick


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

Bug#766796: konqueror: Konqueror is vulnerable to the Poodle attack

[Patrick Häcker]

Package: konqueror
Version: 4:4.14.1-1
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

according to https://www.poodletest.com/ Konqueror is still vulnerable to the
Poodle attack.
If this is only fixable in KHTML or WebKit, please move the bug there.

As all the other major browsers plan to deactivate SSLv3 support in the near
future, Konqueror should probably do so as well for Jessie.

Kind regards
Patrick

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages konqueror depends on:
ii  install-info5.2.0.dfsg.1-4
ii  kde-baseapps-bin4:4.14.1-1
ii  kde-baseapps-data   4:4.14.1-1
ii  kde-runtime 4:4.14.1-1+b1
ii  libc6   2.19-11
ii  libkactivities6 4:4.13.3-1
ii  libkcmutils44:4.14.1-1+b1
ii  libkde3support4 4:4.14.1-1+b1
ii  libkdecore5 4:4.14.1-1+b1
ii  libkdesu5   4:4.14.1-1+b1
ii  libkdeui5   4:4.14.1-1+b1
ii  libkfile4   4:4.14.1-1+b1
ii  libkhtml5   4:4.14.1-1+b1
ii  libkio5 4:4.14.1-1+b1
ii  libkonq5abi14:4.14.1-1
ii  libkonqsidebarplugin4a  4:4.14.1-1
ii  libkparts4  4:4.14.1-1+b1
ii  libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-qt3support   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-xml  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtcore4  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtgui4   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libstdc++6  4.9.1-16
ii  libx11-62:1.6.2-3

Versions of packages konqueror recommends:
ii  dolphin  4:4.14.1-1
ii  kfind4:4.14.1-1
ii  konqueror-nsplugins  4:4.14.1-1
ii  kpart-webkit 1.3.4-1

Versions of packages konqueror suggests:
ii  konq-plugins  4:4.14.1-1

-- no debconf information


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

Bug#753471: konqueror: Black picture when trying to play youtube videos using html5

[Patrick Häcker]

On Wed, 2 Jul 2014 10:45:17  0200 Petter Reinholdtsen  
wrote:
> Package: konqueror
> Version: 4:4.12.4-1
> Severity: normal
> 
> When I visit youtube on a freshly installed Jessie desktop and try to
> watch a video, the video player seem to start as it should, show the
> duration and playout position, and even play the sound sound, but
> there is no image.  Only a black video frame.

I can confirm this issue with version 4:4.14.1-1 with both the KHTML and the 
WebKit mode. It does not work for 4:4.8.4-2, too.

The corresponding upstream bug report seems to be
https://bugs.kde.org/show_bug.cgi?id=229218

Visiting http://www.quirksmode.org/html5/tests/video.html, this seems to be a 
H.264/MP4 related problem, as both WebM and Ogg/Theora work (tested with 
4:4.14.1-1 and WebKit) and only H.262/MP4 plays sound without pictures.

I activated some debugging in kdebugdialog, but I couldn't spot anything 
obvious, though that might have gone lost in the noise.

It might be related to this bug report:
https://bugs.kde.org/show_bug.cgi?id=253061
If that should be true, QtWebKit would be related.
This seems similar to this report:
https://github.com/QupZilla/qupzilla/issues/573

In
http://stackoverflow.com/questions/3066055/qtwebkit-problems-playing-html5-video
it's mentioned, that Phonon might also be relevant. Switching the phonon 
backend from gstreamer to vlc seems to stop Ogg/Theora support on the above 
test page, although it dose not change the support for H.264/MP4 videos. But 
there definitely seems to be a relationship.

I tried Rekonq and the support on
http://www.quirksmode.org/html5/tests/video.html
is identical to that of Konqueror using Konqueror's WebKit mode. So it does 
not seem to be something Konqueror specific.

Then again, Arora, another WebKit based browser, works and supports all three 
files on testpage mentioned above.
Arora is linked against Qt5 and Qt5WebKit, while both Konqueror and Rekonq 
are linked against Qt4 and the latter one also against libQtWebKit version 4.

So it really seems to be QtWebKit4 related.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#762402: KWallet Integration with PAM

[Patrick Häcker]

> I have just upgraded all the packages in my Debian Testing to the latest 
> ones and I don't know which one did the trick, but auto-unlock of 
> kwallet now works. It works with kdm as well as lightdm.
Ok, this is good news. So the checklist should include "system is up-to-
date".

> This would be a very useful feature to have in Jessie. I, myself being a 
> DM can take this up. Let me first try to contact the Ubuntu maintainers 
> of this package and try to get their opinion.
Working together (I think there was a plan, that the KDE teams of Ubuntu and 
Debian will collaborate more in the future) definitely makes sense here. 
However, the freeze for Jessie is coming close, especially as this package 
should go through NEW and needs additional 10 days to get from unstable to 
testing.
So it might be safer to basically copy the Ubuntu package and upload it to 
Debian now and sort out the collaboration model with Ubuntu later.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#747514: systemd breaks kexec-tools

[Patrick Häcker]

> I'd like to have his input on what we need to do within systemd.
With kexec-tools 1:2.0.7-3 kexec works with systemd when using the reboot 
command.

> I notice systemd also has a "systemctl kexec" command. Have you tried
> that? If that doesn't work, we probably need to fix that integration as
> well.
Unfortunately, "systemctl kexec" does still not work, or at least not as you 
would expect having kexec-tools in mind.
http://lists.freedesktop.org/archives/systemd-devel/2012-March/004760.html
implies, that systemd is executing the already loaded kernel, but does not 
load an kernel itself.

This behavior certainly has its use cases, though I think it's not clear in 
the documentation (systemctl's man page). So before this bug can be closed, 
the documentation should probably be improved, adding something like:

"This option reboots using kexec with a kernel which must manually be loaded 
beforehand using 'kexec --load'. If no kernel has been loaded, this option 
does a reboot without using kexec, even if kexec is configured as default for 
regular reboots in /etc/default/kexec."

Interestingly, if you have kexec configured as default, but really want to do 
a complete reboot through the system firmware, using "systemctl kexec" is the 
way to go. This is a bit unexpected, but can be quite useful.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#744006: Package: arora: Arora does not start due to a segmentation fault.

[Patrick Häcker]

control: severity -1 grave

>  Arora started to open and then immediately closed.  The message 
> "Segmentation fault" appeared.
I can confirm this behavior. The following is the gdb output. As I found 
neither arora nor libqtgui debugging packages, it might not be that helpful, 
though.

> (gdb) file arora
> Reading symbols from arora...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/arora
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffe5e95700 (LWP 7294)]
> [New Thread 0x7fffe527e700 (LWP 7295)]
> [New Thread 0x7fff9f8f1700 (LWP 7296)]
> [New Thread 0x7fff9ea7b700 (LWP 7297)]
> [New Thread 0x7fff9e27a700 (LWP 7298)]
> [New Thread 0x7fff9da79700 (LWP 7299)]
> [New Thread 0x7fff9d278700 (LWP 7300)]
> [New Thread 0x7fff9ca77700 (LWP 7301)]
> [New Thread 0x7fff87fff700 (LWP 7302)]
> [New Thread 0x7fff848a1700 (LWP 7303)]
> [New Thread 0x7fff7700 (LWP 7304)]
> [New Thread 0x7fff7ebdf700 (LWP 7305)]
> [New Thread 0x7fff7e3de700 (LWP 7306)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fff697a0cfc in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4


This is my system information:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-proposed-
updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages arora depends on:
ii  libc6 2.19-11
ii  libgcc1   1:4.9.1-16
ii  libgl1-mesa-glx [libgl1]  10.2.6-1
ii  libqt5core5a  5.3.2+dfsg-3
ii  libqt5gui55.3.2+dfsg-3
ii  libqt5network55.3.2+dfsg-3
ii  libqt5opengl5 5.3.2+dfsg-3
ii  libqt5printsupport5   5.3.2+dfsg-3
ii  libqt5qml55.3.2-4
ii  libqt5quick5  5.3.2-4
ii  libqt5script5 5.3.2+dfsg-2
ii  libqt5sql55.3.2+dfsg-3
ii  libqt5webkit5 5.3.2+dfsg-2
ii  libqt5widgets55.3.2+dfsg-3
ii  libstdc++64.9.1-16

> _
> Most Internet users are unaware that they have porn on their computers.  Be 
Safe.  Protect Your Job and Family!  Learn more by clicking the link below 
Now:
> 
> http://contentpurity.com/cleanintro.htm
> 
> Are you passing through a hard time or need help in making a hard decision 
?  JesusAnswers.com can help.  Please click the link below now:
> 
> http://jesusanswers.com/jesus/salvation.htm

Thanks for reporting this bug. Nevertheless, I would prefer keeping bug 
reports technical. In my opinion discussions about religion have other 
places.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#762402: KWallet Integration with PAM

[Patrick Häcker]

Hi Rahul,

> Did you check this on Debian?
yes, I have this working on two Debian testing systems. 

> 1. Recompiled pam-kwallet_0.0~git20140429-0ubuntu1 in Debian testing and 
> installed it
Instead of recompiling it, I installed the binary package provided by Ubuntu 
without modifying it. I haven't tested recompilation, yet. Does the Ubuntu 
package work for you? As a debugging approach, I recommend to test the binary 
first and test recompiling only if the binary package works.

Have you installed all dependencies? You have to install these:
> libc6 (>= 2.4), libgcrypt11 (>= 1.5.1), libpam0g (>= 0.99.7.1), socat
I read that on one system socat has been missing, if I remember correctly.

> 2. Updated kde-workspace to the latest version in testing (4.11.12)
I have the package with version 4:4.11.12-2 installed, so this should be 
identical.

> 3. Modified /etc/pam.d/lightdm to include the two lines that you have 
> mentioned
When trying to get pam-kwallet working, I added these and other lines on 
multiple places, and it did not work. It did work when the only lines I 
modified have been these two lines. I am not absolutely sure that adding 
other pam-kwallet entries has been the problem (as I might have changed 
multiple things), but I would recommend against it while trying to get it to 
work.

> However, it does not work. This is the output that I see in 
> /var/log/auth.log
> Oct 12 22:02:10 rahul-laptop lightdm: pam_kwallet(lightdm:session): 
> pam-kwallet: final socket path: /tmp//rahul.socket
I see the same (though I use the Journal, but that should not make a 
difference), but I also get lines like this:
> pam_kwallet(lightdm:session): pam_sm_open_session

> In /var/log/lightdm/lightdm.log, I do not see any messages related to 
> kwallet
I can confirm this, I also do not have anything logged there (and the ctime 
is quite current even when using the Journal).

> but ps aux | grep kwalletd returns this.
> 
> rahul21702  0.0  0.0  0 0 ?Z22:19   0:00 
> [kwalletd] 
> rahul21772  1.9  0.2  96960 19268 ?SL   22:19   0:01 
> /usr/bin/kwalletd --pam-login 9 12
I have the same two processes (with file descriptors 10 and 14 at the moment, 
but 9 and 12 sound plausible, too).

> Am I missing any configuration step?
This following is probably obvious, but I better mention it so that you do 
not unnecessarily lose time debugging it.

In the setup described by me, you have to use lightdm. I use the package with 
version 1.10.2-2 with a fixed config to avoid #762211. Using the package from 
unstable should work, too.

Do you really use identical passphrases for your user and your wallet?

It also might work already without you noticing it. I think, that only your 
default wallet will be opened. Although it might be that other wallets are 
not opened as they have different passphrases. I have only two checkboxes 
selected in the KDE wallet properties: "Enable the KDE wallet subsystem" and 
"Show manager in system tray". I do not have a default wallet selected. Check 
the tray icon after login to see if you wallet has been opened.

I have read, that pam-kwallet only works with the traditional wallets and not 
with the more recent GPG-based wallets. Though, I have only tested the former 
and not the latter.

It is a known bug 
(https://www.redhat.com/archives/pam-list/2014-October/msg0.html) that 
pam-kwallet does not work if pam-mount is used to 
unlock a (user's) home file system at the same time. So either avoid pam-
mount in your tests, or ensure that the file system is already unlocked when 
testing pam-kwallet with lightdm.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#762211: [Pkg-xfce-devel] Bug#762211: lightdm crashes on startup, system falls back to console

[Patrick Häcker]

> > The problematic line in my setup is
> > > greeter-session=lightdm-kde-greeter
> 
> This one has been manually added. You're basically saying lightdm the
> greeter is lightdm-kde-greeter. If you don't have it installed, then it
> obviously can't start it, so it might be worth double checking that.

Sorry for not being precise. I had and still have it installed:
> dpkg -l | grep ' lightdm'
> ii  lightdm  1.10.2-2   amd64   simple display manager
> ii  lightdm-kde-greeter  0.3.2.2-1  amd64   LightDM KDE greeter

But instead of being used, that line produces the following error (with 
varying memory address) crashing lightdm:
> *** Error in `/usr/sbin/lightdm': double free or corruption (fasttop): 
0x7ff6ca2175f0 ***

> > As Fabio Rosciano has the line
> > > greeter-session=lightdm-greeter
> > in his config, too, this is very likely the culprit.
> 
> lightdm-greeter is the correct setting, lightdm-greeter is managed using
> the alternatives system, so if you remove a greeter the system will
> switch to another greeter automatically.

Yes, but I guess that as soon as the key "greeter-session" appears in the 
config file, lightdm 1.10.2-2 crashes. It definitely does it on my computer 
with the value "lightdm-kde-greeter". I haven't checked other values, but I 
can do that if you tell me which values I should check.

> Yup, greeter-hide-users was previously set (to true)
> in /e/l/lightdm.conf, and is now set
> in /usr/share/lightdm/lightdm.conf.d/01_debian.conf.
> 
> So, can you actually check which one is actually making lightdm crash?

The former one lets lightdm crash. "greeter-hide-users" does not seem to have 
anything to do with the crash. I just wanted to mention it, as the 
configuration with both keys set seems to be quite common, which is why this 
crash should be fixed without the need that everyone removes the "greeter 
session" key from his config.

Kind regards
Patrick

P. S. If you can't reproduce it: Both Fabio Rosciano have an amd64 system. It 
might be different on an i386 system.

signature.asc
Description: This is a digitally signed message part.

Bug#763281: konqueror: Session management does not work for Konqueror

[Patrick Häcker]

control: tags -1 patch

> So now we know, that 4:4.13.3-1 is the last known good package and
> 4:4.14.0-1 the first known bad package. We also know, that saving, not
> loading the session really is the problem.
> So there seems to be another idea needed to further debug the problem.
 
As all 5 packages come from the same source package (according to
https://packages.qa.debian.org/k/kde-baseapps.html), I downloaded this
package in both versions with
> debsnap kde-baseapps 4:4.14.0-1
> debsnap kde-baseapps 4:4.13.3-1
unpacked the archives and looked with kdiff3 for interesting changes.

One interesting change is inside of
> kde-baseapps-4.1?.?/konqueror/src/konqmainwindow.cpp
in lines 5193 until 5196, where effectively
> if (isPreloaded() && !kapp->sessionSaving()) {
> hide();
> }
is changed into
> if (stayPreloaded() && !kapp->sessionSaving()) {
> e->ignore();
> hide();
> }
Thus, the main window's close event gets ignored (whatever that means) and 
the condition is changed from isPreloaded to stayPreloaded. So preloading 
might be involved into this bug.

I just checked my Konqueror settings and my background process 
configuration is "2", "no", "no". I changed it to "3", "yes", "yes", but this 
does not change nor fix the session management behavior with 4:4.14.0-1.

Here goes nothing! I should be able to build the package myself so 
that I can test changes. To get the build dependencies, I executed
> apt-get build-dep kde-baseapps
which installed some development packages and downloaded the most recent 
version with
> apt-get source kde-baseapps
I can now build the packages by using
> cd kde-baseapps-4.14.1; fakeroot dpkg-buildpackage -j6 -b -uc -us

After reverting the change above in 4:4.14.1.1, rebuilding the package and 
installing it, Konqueror's session management works again.

For the record, this is the diff between the working and the breaking commit:
https://projects.kde.org/projects/kde/applications/kde-baseapps/repository/diff/konqueror/src/konqmainwindow.cpp?rev=0f149f4469677e8c830962c748fca4d5aa2fbf9e&rev_to=af5a796edddefb08f9d7c02068a6e891a327b25a

The commit message
> Port away from queryExit().
> stayPreloaded() already checks whether this is the last window.
already sounds as this has not been the best commit, as you can't port away 
from something, which is already commented or unused code.

Dear maintainer, please revert this commit and upload the changed packages.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#763281: konqueror: Session management does not work for Konqueror

[Patrick Häcker]

> So now we know, that 4:4.13.3-1 is the last known good package and 
> 4:4.14.0-1 the first known bad package. We also know, that saving, not
> loading the session really is the problem.

Unfortunately, it does not seem to be easily possible to track the exact 
package down. According to
> find *.deb | xargs --max-args 1 dpkg --info
the three packages
> konqueror
> kde-baseapps-bin
> kde-baseapps-data
are completely coupled via an exact version depends (=).

Although it is possible to install these 3 with version 4:4.14.0-1 and the 
other 2 with version 4:4.13.3-1, this breaks session management completely 
for konqueror, i.e. konqueror does not even load with an empty tab anymore.

The reverse version selection is not installable. So there seems to be 
another idea needed to further debug the problem.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#763281: konqueror: Session management does not work for Konqueror

[Patrick Häcker]

> Anyway, doing the same with version 4:4.13.3-1 could be interesting, but 
> resolving the dependencies could be more tricky. If you want to try it, that 
> is the approach for 4:4.14.0-1 (the last one obviously needs root 
> permissions):
> > debsnap --architecture all kde-baseapps-data 4:4.14.0-1
> > debsnap --architecture all kde-baseapps 4:4.14.0-1
> > debsnap --architecture amd64 kde-baseapps-bin 4:4.14.0-1
> > debsnap --architecture amd64 kdepasswd 4:4.14.0-1
> > debsnap --architecture amd64 konqueror 4:4.14.0-1
> > find binary* -type f | xargs dpkg -i

I just did the downgrade of the above packages to 4:4.13.3-1 and session 
management is working again. I had a typo in the commands of the last mail 
(fixed above to avoid confusion), as it obviously must be "amd64" instead of 
"amd" (or whatever architecture you are using), so the correct commands are
> debsnap --destdir . --architecture all kde-baseapps-data 4:4.13.3-1
> debsnap --destdir . --architecture all kde-baseapps 4:4.13.3-1
> debsnap --destdir . --architecture amd64 kde-baseapps-bin 4:4.13.3-1
> debsnap --destdir . --architecture amd64 kdepasswd 4:4.13.3-1
> debsnap --destdir . --architecture amd64 konqueror 4:4.13.3-1
> dpkg -i *.deb

Then, as a plausibility check, I upgraded from 4:4.13.3-1 to 4:4.14.0-1 again. 
After the first logout/login, konqueror restored the session correctly, as the 
session has been saved with a 4:4.13.3-1 version and loading with 4:4.14.0-1 
seems to work. Another logout/login later, the session management stopped 
working again.

So now we know, that 4:4.13.3-1 is the last known good package and 4:4.14.0-1 
the first known bad package. We also know, that saving, not loading the 
session really is the problem.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#763281: konqueror: Session management does not work for Konqueror

[Patrick Häcker]

On Thu, 02 Oct 2014 22:02:15 -0400 Brendon Higgins 
 wrote:
> I'm also experiencing this, on three different computers.

Do you know when this behavior started? Are you using testing or unstable? 
According to
https://packages.qa.debian.org/k/kde-baseapps.html
there are not so many possible versions which could introduce this bug in my 
(mainly) testing system:
4:4.14.1-1 at 2014-09-26 or
4:4.14.0-1 at 2014-08-30 or
4:4.13.3-1 at 2014-08-05
I am quite sure, that the bug has not not occurred since or before 2014-05-05.

Given the lack of upstream maintainers, we probably have to care about this 
bug ourselves, if we want to get it fixed for Jessie. I checked
> ~/.kde/share/config/ksmserverrc
and it contains an entry of konqueror, which seems valid to me. This is 
plausible, as konqueror automatically opens when logging in, after all.
Then I checked the files in
> ~/.kde/share/config/session
and current konqueror entries lack nearly all data. So it does not seem to be 
a problem with restoring (reading) the session managemant information, but 
with storing (saving) it.

I found an old entry modified (created) on 2014-08-06 in that directory which 
seems to contain all needed data. According to my /var/log/dpkg.log.1 file, I 
upgraded konqueror  from 4:4.12.4-1 to 4:4.13.3-1 on 2014-08-05 in the 
evening. As I shut my system down later that evening, the correct session file 
must have been created with version 4:4.13.3-1. Thus, I think, the bug must 
have been introduced in KDE with 4:4.14.0-1 or 4:4.14.1-1. It would be 
helpful, if you could narrow it down even more.

By the way, I already downgraded konqueror, kde-baseapps-data, kdepasswd, kde-
baseapps and kde-baseapps-bin to 4:4.14.0-1 versions, but that didn't help. 
Either the problem has already been present in the 4:4.14.0-1 version or 
another KDE component is the culprit, as konqueror probably uses other 
libraries/processes to save its session management data.
Anyway, doing the same with version 4:4.13.3-1 could be interesting, but 
resolving the dependencies could be more tricky. If you want to try it, that 
is the approach for 4:4.14.0-1 (the last one obviously needs root 
permissions):
> debsnap --architecture all kde-baseapps-data 4:4.14.0-1
> debsnap --architecture all kde-baseapps 4:4.14.0-1
> debsnap --architecture amd kde-baseapps-bin 4:4.14.0-1
> debsnap --architecture amd kdepasswd 4:4.14.0-1
> debsnap --architecture amd konqueror 4:4.14.0-1
> find binary* -type f | xargs dpkg -i

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#762211: lightdm crashes on startup, system falls back to console

[Patrick Häcker]

On Sun, 28 Sep 2014 21:43:08 +0200 Yves-Alexis Perez  
wrote:
> > sorry for the delayed reply. I could indeed confirm that the problem is
> > in the config file. Keeping the old config files breaks the upgrade,
> > while installing the new ones has no problem.
> > Here is the offending lightdm.conf:
> > 
> > http://pastebin.com/RmcGJiNj
> 
> A quick look doesn't reveal anything offending, but now that you
> identified the cause you can “bisect” to find the offending line, I
> guess.

I did exactly that, as I have been bitten by that bug, too. The problematic 
line in my setup is
> greeter-session=lightdm-kde-greeter
If it is active, lightdm fails to start, if it is commented, lightdm works. In 
the package's current config file, this line does not exist.

As Fabio Rosciano has the line
> greeter-session=lightdm-greeter
in his config, too, this is very likely the culprit.

The next line
> greeter-hide-users=false
is at the same place and active both in our conf files. Thus I think these 
lines have been created automatically, shipped by an older version or came 
from some tutorial. Therefore it's important, that lightdm can cope with this 
line without crashing, as this will hit more users and some users won't have 
the skill needed to remove a line in a config file when upgrading to Jessie.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#763850: imwheel: Version 1.0.0pre12-10 fails to start

[Patrick Häcker]

Package: imwheel
Version: 1.0.0pre12-10
Severity: important
Tags: patch

Dear Maintainer,

updating the package from 1.0.0pre12-9 to 1.0.0pre12-10 let imwheel fail at
startup. As written in the changelog, I tried some variants of quotes in
/etc/X11/imwheel/startup.conf and especially the variant delivered in the
package's original config file. They all do not work.

This can be fixed by changing
> ${IMWHEEL_PARAMS}
into
> "$IMWHEEL_PARAMS"
in /etc/X11/Xsession.d/60imwheel_start-imwheel and changing
> IMWHEEL_PARAMS=-b "0 0 0 0 8 9"
into
> IMWHEEL_PARAMS='-b "0 0 0 0 8 9"'
in /etc/X11/imwheel/startup.conf

This has been tested in bash and dash and basically reverts version
1.0.0pre12-10. I am a bit puzzled about that, because if the new version had
been tested by starting it up once, this bug should not have happened, so
there might be something I overlook. /etc/X11/Xsession uses /bin/sh, so your 
mileage may vary with other shells, but as dash is the default system shell,
imwheel has to work with that out of the box.

Kind regards
Patrick


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages imwheel depends on:
ii  libc6 2.19-11
ii  libx11-6  2:1.6.2-3
ii  libxmu6   2:1.1.2-1
ii  libxtst6  2:1.2.2-1

imwheel recommends no packages.

imwheel suggests no packages.

-- Configuration Files:
/etc/X11/imwheel/imwheelrc changed [not included]
/etc/X11/imwheel/startup.conf changed [not included]

-- no debconf information


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

Bug#683508: [Pkg-xfce-devel] Bug#683508: lightdm: Error messages about gnome keyring in auth.log

[Patrick Häcker]

On Sonday, 28. September 2014, 21:47:43 Yves-Alexis Perez wrote:
> On dim., 2014-09-28 at 10:28 +0200, Patrick Häcker wrote:
> > So change the lines
> > 
> > > auth optional pam_gnome_keyring.so
> > > session optional pam_gnome_keyring.so auto_start
> > 
> > into
> > 
> > > -auth optional pam_gnome_keyring.so
> > > -session optional pam_gnome_keyring.so auto_start
> > 
> > in file /etc/pam.d/lightdm to tell PAM to ignore pam_gnome_keyring.so if
> > it is missing.
> > 
> > I didn't create a patch file, as the fix is straightforward, although I
> > can do that if necessary.
> 
> Let's do that and see how it goes.

How is the word "that" meant in the above sentence? Do you mean to use the 
proposed solution or do you mean I should create a patch?

> The log error is generally useful for people which are actually
> expecting this to work and looking at the log to check why it doesn't,
> but we can try and always revert back later.

I agree. The log error is useful for those who expect the module to be 
available and useless for those who expect the module to be missing. A falsely 
missing module should be very rare, but finding the root of the problem will 
be time consuming without the warning. The false warning is common, but does 
only little harm (obfuscate and unsettle).

Both solutions are not perfect. As written, the ideal solution would probably 
depend on the installed packages and some .d-directories. Nevertheless, I 
think this heads into the right direction.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#763281: konqueror: Session management does not work for Konqueror

[Patrick Häcker]

Package: konqueror
Version: 4:4.14.1-1
Severity: normal

Dear Maintainer,

on two different computers, the session management does not work any longer
for Konqueror, i.e. logging out and in again does not restore the opened tabs
in Konqueror.

Kind regards
Patrick

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages konqueror depends on:
ii  install-info5.2.0.dfsg.1-4
ii  kde-baseapps-bin4:4.14.1-1
ii  kde-baseapps-data   4:4.14.1-1
ii  kde-runtime 4:4.14.1-1
ii  libc6   2.19-11
ii  libkactivities6 4:4.13.3-1
ii  libkcmutils44:4.14.1-1
ii  libkde3support4 4:4.14.1-1
ii  libkdecore5 4:4.14.1-1
ii  libkdesu5   4:4.14.1-1
ii  libkdeui5   4:4.14.1-1
ii  libkfile4   4:4.14.1-1
ii  libkhtml5   4:4.14.1-1
ii  libkio5 4:4.14.1-1
ii  libkonq5abi14:4.14.1-1
ii  libkonqsidebarplugin4a  4:4.14.1-1
ii  libkparts4  4:4.14.1-1
ii  libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqt4-qt3support   4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqt4-xml  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtcore4  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtgui4   4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libstdc++6  4.9.1-14
ii  libx11-62:1.6.2-3

Versions of packages konqueror recommends:
ii  dolphin  4:4.14.1-1
ii  kfind4:4.14.1-1
ii  konqueror-nsplugins  4:4.14.1-1
ii  kpart-webkit 1.3.4-1

Versions of packages konqueror suggests:
ii  konq-plugins  4:4.14.1-1

-- no debconf information


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

Bug#683508: lightdm: Error messages about gnome keyring in auth.log

[Patrick Häcker]

> I do not have gnome-keyring-daemon installed.  Why is it trying to
> start it?
You are correct that in an ideal solution this line should only be present if 
gnome-keyring-daemon is installed. However, the rest of the configuration 
should be in the responsibility of the lightdm package (or other packages with 
the same problem as gnome-keyring-daemon). Modifying configuration files from 
other packages is always fragile, so this is probably no improvement. The 
cleanest solution would be to have a directory structure as in the other 
/etc/*.d directories. But this might be overkill to have that for nearly every 
entry in /etc/pam.d (and I do not know if there is a problem nesting two .d-
directories).

> Would it be possible to change /etc/pam.d/lightdm in a way that no
> error/warning appears if the module is not installed?
Besides the error, having an additional line in the lightdm configuration does 
not seem to do much harm. So it would be enough to avoid this error. This is 
indeed easily possible by adding a leading minus sign to the entries (the 
"optional" keyword is, unfortunately, not enough).

So change the lines
> auth optional pam_gnome_keyring.so
> session optional pam_gnome_keyring.so auto_start
into
> -auth optional pam_gnome_keyring.so
> -session optional pam_gnome_keyring.so auto_start
in file /etc/pam.d/lightdm to tell PAM to ignore pam_gnome_keyring.so if it is 
missing.

I didn't create a patch file, as the fix is straightforward, although I can do 
that if necessary.

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#762402: RFP: pam-kwallet -- KWallet integration with PAM

[Patrick Häcker]

This is a correction to the procedure described above. Instead of adding the 
lines to lightdm-greeter,
> -auth optional pam_kwallet.so
> -session optional pam_kwallet.so auto_start
should instead be added to /etc/pam.d/lightdm (without "-greeter" in the 
name).

Please note the leading minus sign in the lines above. They avoid logged 
errors if the pam-kwallet package is not installed and the above 
pam_kwallet.so entries are present.

I do not know if there is any advantage in putting these lines into lightdm-
greeter. Just putting them into lightdm works.

Kind regards
Patrick

Am Sonntag, 21. September 2014, 23:58:09 schrieb Patrick Häcker:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: pam-kwallet
>   Version : 0.0~git20140429-0ubuntu1
>   Upstream Author : Alejandro Fiestas Olivares (afies...@kde.org)
> * URL :
> https://www.dennogumi.org/2014/04/unlocking-kwallet-with-pam/ * License
> : GPL
>   Programming Lang: C
>   Description : KWallet integration with PAM
> 
> Integrated KWallet with PAM so you can log in to open a KWallet.
> 
> Entering a KWallet password directly after entering the (possibly identical)
> login password is redicoulus (see
> https://bugs.kde.org/show_bug.cgi?id=92845 for more details). This is one
> of KDE's biggest usability problems and one of the most voted bug reports,
> which correlates with my experience supporting Debian/KDE users.
> 
> The upstream support for KDE 4 (and thus probably Jessie) is kind of a mess.
> However, Kubuntu took the upstream code and already made a package, which
> works for Jessie, too:
> http://packages.ubuntu.com/de/trusty/amd64/pam-kwallet
> 
> It would be great if a DM or DD could upload this small package (less than
> 600 LOC) to Debian in time for Jessie.
> 
> After installing the package, the following two lines
> 
> > auth optional pam_kwallet.so
> > session optional pam_kwallet.so auto_start
> 
> should be added to /etc/pam.d/lightdm-greeter (from the lightdm package).
> 
> With these changes and if the login password is identical to the KWallet
> password, the default wallet (kdewallet) should get opened automatically
> after login.
> 
> Kind regards
> Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#762402: RFP: pam-kwallet -- KWallet integration with PAM

[Patrick Häcker]

Package: wnpp
Severity: wishlist

* Package name: pam-kwallet
  Version : 0.0~git20140429-0ubuntu1
  Upstream Author : Alejandro Fiestas Olivares (afies...@kde.org)
* URL : 
https://www.dennogumi.org/2014/04/unlocking-kwallet-with-pam/
* License : GPL
  Programming Lang: C
  Description : KWallet integration with PAM

Integrated KWallet with PAM so you can log in to open a KWallet.

Entering a KWallet password directly after entering the (possibly identical)
login password is redicoulus (see https://bugs.kde.org/show_bug.cgi?id=92845
for more details). This is one of KDE's biggest usability problems and one of
the most voted bug reports, which correlates with my experience supporting
Debian/KDE users.

The upstream support for KDE 4 (and thus probably Jessie) is kind of a mess.
However, Kubuntu took the upstream code and already made a package, which
works for Jessie, too:
http://packages.ubuntu.com/de/trusty/amd64/pam-kwallet

It would be great if a DM or DD could upload this small package (less than
600 LOC) to Debian in time for Jessie.

After installing the package, the following two lines
> auth optional pam_kwallet.so
> session optional pam_kwallet.so auto_start
should be added to /etc/pam.d/lightdm-greeter (from the lightdm package).

With these changes and if the login password is identical to the KWallet
password, the default wallet (kdewallet) should get opened automatically
after login.

Kind regards
Patrick


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

Bug#760513: netfilter-persistent: Postinst aborts with an error

[Patrick Häcker]

I found the root problem and could fix it. It was a configuration problem 
(nearly) unrelated to netfilter-persistent. Due to netfilter-persistent's 
systemd file, modules have been loaded via a systemd dependency. 

This caused /etc/modules being executed, which contained the line
> snd_hda_intel power_save=1
which seems to be valid according to
> modinfo snd_hda_intel
but systemd failed anyway to execute this (with kernel 3.15) and and thus did 
abort to load netfilter-persistent. As netfilter-persistent is loaded in the 
postinst script, the configuration of the package failed.

I will close this bug report and hope that the above information can help if 
someone has a similar problem.

signature.asc
Description: This is a digitally signed message part.

Bug#760513: netfilter-persistent: Postinst aborts with an error

[Patrick Häcker]

Package: netfilter-persistent
Version: 1.0.2
Severity: normal
Tags: ipv6

Dear Maintainer,

installing netfilter-persistent (systemd active) results in the following error:
> dependency job for netfilter-persistent.service failed. See 'journalctl -xn' 
> for details.
> invoke-rc.d: initscript netfilter-persistent, action "start" failed.

It also mentions, that dpkg failed due to netfilter-persistent's postinstall
having an error.

Accessing the mentioned command results in the following output:
> Sep 04 23:19:29 mmm systemd[1]: Dependency failed for netfilter persistent 
> configuration.
> -- Subject: Unit netfilter-persistent.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> -- 
> -- Unit netfilter-persistent.service has failed.
> -- 
> -- The result is dependency.

Please note, that netfilter-persistent had already been installed on this
system before. Purging and reinstalling the package does not solve the problem.

Kind regards
Patrick

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.15-trunk-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages netfilter-persistent depends on:
ii  init-system-helpers  1.21
ii  lsb-base 4.1+Debian13

netfilter-persistent recommends no packages.

netfilter-persistent suggests no packages.

-- no debconf information


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

Bug#755533: debian-installer: Use GeoIP support in installer

[Patrick Häcker]

> > it would be nice, if Debian installer would support GeoIP to use default
> > values where appropriate.
> 
> I don't think we're going to set up networking without asking, let alone
> contacting some service on the internets to figure out what country the
> user might be in.

Good point, I didn't think about the privacy (and potentially security) 
concerns.

An additional button "try to get some default values automatically" with the 
necessary explanations of your valid concerns is probably not helpful, as the 
user didn't even select his language, thus in general can't read neither the 
button nor the text.

But if I give a Debian image to Joe User, he will expect to have an 
installation, which is as easy as possible without resulting in wrong settings
(so the selected language should be correct, for example).

If we had a "simple install" mode next to the "normal install" and the "expert 
install" I'd suggest to make GeoIP the default for the "simple install" and 
deactivate it for the other two modes. But as we do not have that, I could 
imagine having it active in the normal install and using a Debian server 
secured by TLS (if that's possible with GeoIP, I didn't check).

Regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#755533: debian-installer: Use GeoIP support in installer

[Patrick Häcker]

Package: debian-installer
Severity: wishlist
Tags: d-i l10n

Dear Maintainer,

it would be nice, if Debian installer would support GeoIP to use default
values where appropriate. See
http://henrich-on-debian.blogspot.de/2014/07/geoip-support-for-installer-is-really.html
for an example.

This would probably change the required order of the installer steps. But as
a start, it would probably be enough to check if a DHCP enabled network
interface is available and use GeoIP only then. Otherwise the normal steps
should be executed.

Kind regards
Patrick


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

Bug#750997: linux-image-3.15-rc7-amd64: Kernel message "Uhhuh. NMI received for unknown reason 2c on CPU 0." appears after suspend to disk

[Patrick Häcker]

Package: src:linux
Version: 3.15~rc7-1~exp1
Severity: normal

Dear Maintainer,

some seconds or minutes after waking up from suspend to disk after the NMI
watchdog has been disabled (e.g. with powertop or with "echo 0 >
/proc/sys/kernel/nmi_watchdog") before suspend, I get the following message
from the kernel:

> Uhhuh. NMI received for unknown reason 2c on CPU 0.
> Do you have a strange power saving mode enabled?
> Dazed and confused, but trying to continue

The exact timing seems to differ from run to run. The problem seems to be
identical to the problem reported here:
http://linux-kernel.2935.n7.nabble.com/Uhhuh-NMI-received-for-unknown-reason-2c-on-CPU-0-tp591524p628729.html
Please note that the linked thread is interleaved with an independent e1000
networking problem. The NMI problem seems to be unrelated from e1000 there
and it definitely is unrelated here, as no e1000 is loaded or plugged-in.

I only tested 3.15, RC7, but I guess, that the problem occurs with older
kernels, too, and that I didn't see it before, as I just recently switched
the aforementioned watchdog option. I can test different kernels if this
helps, but as the kernels works without any obvious problems, I haven't done
this, yet.

The end of a restore from disk run looks like the following:
[29240.016685] PM: restore of devices complete after 2379.959 msecs
[29240.017030] PM: Image restored successfully.
[29240.017063] PM: Basic memory bitmaps freed
[29240.017064] Restarting tasks ... done.
[29423.719271] Uhhuh. NMI received for unknown reason 2c on CPU 0.
[29423.719281] Do you have a strange power saving mode enabled?
[29423.719286] Dazed and confused, but trying to continue

Another, more detailed run, looks as follows:
[   69.624048] PM: Hibernation mode set to 'platform'
[   69.969074] (NULL device *): firmware: direct-loading firmware 
amd-ucode/microcode_amd.bin
[   69.969114] PM: Syncing filesystems ... done.
[   70.385415] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   70.387587] PM: Marking nosave pages: [mem 0x00098000-0x000f]
[   70.387600] PM: Marking nosave pages: [mem 0xdff9-0x]
[   70.388839] PM: Marking nosave pages: [mem 0xd400-0xd7ff]
[   70.389642] PM: Basic memory bitmaps created
[   70.389699] PM: Preallocating image memory... done (allocated 218996 pages)
[   71.123610] PM: Allocated 875984 kbytes in 0.73 seconds (1199.97 MB/s)
[   71.123612] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[   71.125251] Suspending console(s) (use no_console_suspend to debug)
[   71.175132] PM: freeze of devices complete after 49.868 msecs
[   71.176441] PM: late freeze of devices complete after 1.304 msecs
[   71.177795] PM: noirq freeze of devices complete after 1.350 msecs
[   71.179148] ACPI: Preparing to enter system sleep state S4
[   71.180007] PM: Saving platform NVS memory
[   71.180527] Disabling non-boot CPUs ...
[   71.182262] kvm: disabling virtualization on CPU1
[   71.282478] smpboot: CPU 1 is now offline
[   71.284767] kvm: disabling virtualization on CPU2
[   71.284775] smpboot: CPU 2 is now offline
[   71.286771] kvm: disabling virtualization on CPU3
[   71.286823] smpboot: CPU 3 is now offline
[   71.288525] kvm: disabling virtualization on CPU4
[   71.390451] smpboot: CPU 4 is now offline
[   71.392044] kvm: disabling virtualization on CPU5
[   71.494456] smpboot: CPU 5 is now offline
[   71.494801] PM: Creating hibernation image:
[   71.667480] PM: Need to copy 220062 pages
[   71.667481] PM: Normal pages needed: 220062 + 1024, available pages: 2908835
[   71.495930] PM: Restoring platform NVS memory
[   71.496021] PCI-DMA: Resuming GART IOMMU
[   71.496021] PCI-DMA: Restoring GART aperture settings
[   71.496195] LVT offset 1 assigned for vector 0x400
[   71.496203] IBS: LVT offset 1 assigned
[   71.496274] Enabling non-boot CPUs ...
[   71.496382] x86: Booting SMP configuration:
[   71.496383] smpboot: Booting Node 0 Processor 1 APIC 0x1
[   71.507336] kvm: enabling virtualization on CPU1
[   71.509428] process: Switch to broadcast mode on CPU1
[   71.509647] CPU1 is up
[   71.509701] smpboot: Booting Node 0 Processor 2 APIC 0x2
[   71.520653] kvm: enabling virtualization on CPU2
[   71.522741] process: Switch to broadcast mode on CPU2
[   71.522914] CPU2 is up
[   71.522976] smpboot: Booting Node 0 Processor 3 APIC 0x3
[   71.533929] kvm: enabling virtualization on CPU3
[   71.536031] process: Switch to broadcast mode on CPU3
[   71.536208] CPU3 is up
[   71.536270] smpboot: Booting Node 0 Processor 4 APIC 0x4
[   71.547221] kvm: enabling virtualization on CPU4
[   71.549333] process: Switch to broadcast mode on CPU4
[   71.549510] CPU4 is up
[   71.549574] smpboot: Booting Node 0 Processor 5 APIC 0x5
[   71.560527] kvm: enabling virtualization on CPU5
[   71.562615] process: Switch to broadcast mode on CPU5
[   71.562789] CPU5 is up
[   71.569418] ACPI: Waking up from system sleep state S4
[   71.584196] PM: noirq restore of devices com

Bug#750979: abtransfers: abTransfers not listed in the KDE menu

[Patrick Häcker]

Package: abtransfers
Version: 0.0.4.1-2
Severity: minor

Dear Maintainer,

abTransfers does not appear in the KDE menu after installing the abtransfers
package (it should be below Applications/Office, but there is no entry
there).
This is strange, as the file /usr/share/menu/abtransfers exists and
seems to be correct. Manual execution of update-menus does not fix the
problem, too. The problem is not user specific. It happens with the old and
the new KDE menu (no other Desktop enviroment installed or tested).

I am not sure, if it is a probem in the abtransfers package, as the menu file
looks correct to me. I have no experience with Debian menu files, but I
checked http://www.debian.org/doc/packaging-manuals/menu.html/ and the
files seems to be valid. Anyway, I wanted to report it against abtransfers,
because it should be so easy to check on another installation, if the menu
exists in another Desktop environment and KDE. The other obvious possible
culprits, KDE and Debian's menu system, can be analyzed afterwards if needed.

Kind regards
Patrick

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.15-rc7-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages abtransfers depends on:
ii  libaqbanking34  5.4.3beta-1
ii  libaqbanking34-plugins  5.4.3beta-1
ii  libc6   2.18-7
ii  libgcc1 1:4.9.0-5
ii  libgwengui-cpp0 4.12.0beta-1
ii  libgwengui-qt4-04.12.0beta-1
ii  libgwenhywfar60 4.12.0beta-1
ii  libqtcore4  4:4.8.6+dfsg-1
ii  libqtgui4   4:4.8.6+dfsg-1
ii  libstdc++6  4.9.0-5

abtransfers recommends no packages.

abtransfers suggests no packages.

-- no debconf information


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

Bug#750573: skrooge: Wrong string in German translation

[Patrick Häcker]

Package: skrooge
Version: 1.9.0-1+b1
Severity: minor

Dear Maintainer,

the account type "wallet" is translated in the German localization of skrooge
as "Passwortspeicher" which means "password safe" (maybe due to the existance
of KWallet?), which is a completely wrong translation. According to
http://skrooge.org/node/117 a wallet should handle cash, i.e. a correct 
translation could either be "Bargeld" (cash) or "Brieftasche" (wallet).


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.15-rc7-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages skrooge depends on:
ii  kde-runtime  4:4.13.1-1
ii  kdepim-runtime   4:4.12.4-2
ii  libakonadi-kde4  4:4.12.4-1
ii  libc62.18-7
ii  libgcc1  1:4.9.0-5
ii  libgrantlee-core00.3.0-5
ii  libkactivities6  4:4.13.1-1
ii  libkcalcore4 4:4.12.4-1
ii  libkdecore5  4:4.13.1-1
ii  libkdeui54:4.13.1-1
ii  libkio5  4:4.13.1-1
ii  libknewstuff3-4  4:4.13.1-1
ii  libknotifyconfig44:4.13.1-1
ii  libkparts4   4:4.13.1-1
ii  libkrosscore44:4.13.1-1
ii  libnepomuk4  4:4.13.1-1
ii  libnepomukutils4 4:4.13.1-1
ii  libofx6  1:0.9.9-2
ii  libplasma3   4:4.13.1-1
ii  libqca2  2.0.3-5
ii  libqca2-plugin-ossl  2.0.0~beta3-2
ii  libqjson00.8.1-3
ii  libqt4-dbus  4:4.8.6+dfsg-1
ii  libqt4-network   4:4.8.6+dfsg-1
ii  libqt4-script4:4.8.6+dfsg-1
ii  libqt4-sql   4:4.8.6+dfsg-1
ii  libqt4-sql-sqlite4:4.8.6+dfsg-1
ii  libqt4-svg   4:4.8.6+dfsg-1
ii  libqt4-xml   4:4.8.6+dfsg-1
ii  libqtcore4   4:4.8.6+dfsg-1
ii  libqtgui44:4.8.6+dfsg-1
ii  libqtwebkit4 2.2.1-7
ii  libsoprano4  2.9.4+dfsg-1
ii  libsqlite3-0 3.8.4.3-3
ii  libstdc++6   4.9.0-5
ii  skrooge-common   1.9.0-1

skrooge recommends no packages.

skrooge suggests no packages.

-- no debconf information


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

Bug#750467: kgpg: KGpg always lists the fingerprint of the subkey even when clicking on the main key

[Patrick Häcker]

Package: kgpg
Version: 4:4.13.1-1
Severity: normal

Dear Maintainer,

nowadays a generated GPG key has a main key and at least one subkey. When
exchanging fingerprints, one normally uses the fingerprint of the main key and
not of the subkey(s). However, KGpg does not show the fingerprint of the main
key. In the GUI only the main key can be selected (the properties of the
subkey cannot be shown). Yet, if you open the properties of the main key, the
fingerprint of the subkey is really shown (without any hint to the subkey, so
this is quite counterintuitive).

This is misleading and should be changed by either only printing the
fingerprint of the main key when viewing the main key's properties or by
additionally listing all subkeys' fingerprints.

To reproduce this, generate a key with a recent gpg version, look at
"gpg --fingerprint" and compare it with KGpg's output.

Kind regards
Patrick

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.15-rc7-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kgpg depends on:
ii  gnupg1.4.16-1.1
ii  gnupg2   2.0.22-3
ii  kde-runtime  4:4.13.1-1
ii  kdepim-runtime   4:4.12.4-2
ii  libakonadi-contact4  4:4.12.4-1
ii  libakonadi-kde4  4:4.12.4-1
ii  libc62.18-7
ii  libkabc4 4:4.12.4-1
ii  libkdecore5  4:4.13.1-1
ii  libkdeui54:4.13.1-1
ii  libkio5  4:4.13.1-1
ii  libkpimutils44:4.12.4-1
ii  libqt4-dbus  4:4.8.6+dfsg-1
ii  libqtcore4   4:4.8.6+dfsg-1
ii  libqtgui44:4.8.6+dfsg-1
ii  libsolid44:4.13.1-1
ii  libstdc++6   4.9.0-5

kgpg recommends no packages.

kgpg suggests no packages.

-- no debconf information


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

Bug#749607: nepomuk-core-runtime: nepomukservicestub with digikamnepomukservice crashes due to invalid memory access

[Patrick Häcker]

The bug seems to be triggered from the digikam-nepomuk-synchronization which I 
activated a long time ago when Digikam had a GUI option for that (this option 
is gone in the mean time). The synchronization seems to be broken: 
https://bugs.kde.org/show_bug.cgi?id=305079#c2 (I do not know how current this 
information is).

Changing in ~/.kde/share/config/digikamrc

> [Nepomuk Settings]
> Sync Digikam to Nepomuk=true
> Sync Nepomuk to Digikam=true

to

> [Nepomuk Settings]
> Sync Digikam to Nepomuk=false
> Sync Nepomuk to Digikam=false

ends the endless loop of nepomukservicestub crashes. So this might be a 
workaround until a true fix is available.

signature.asc
Description: This is a digitally signed message part.

Bug#659260: This bug is even more serious

[Patrick Häcker]

I've also been hit by this bug which wasted not only my, but also a 
developer's time (see #749330).

I can only agree with the other reporters: Arbitrarily resetting kernel 
variables (even on a desktop computer) is out of scope of this package. 
Implementing solution 1 from message #5 needs about 5 minutes and could save 
so much time.

More importantly, changing the DIRTY values to the given values is a bug 
itself. With these values notebooks with a lot of RAM get stalled (see 
http://lwn.net/Articles/572911/ for an explanation). As this is an even larger 
problem (as the solution is identical I didn't open a new bug) because the 
package renders the notebook unusable in some situations (use the link above 
as a manual to reproduce this), I increased the bug's priority.

signature.asc
Description: This is a digitally signed message part.

Bug#749330: pm-utils bug

[Patrick Häcker]

Just for the records: The pm-utils bug is already reported in #659260 (and not 
fixed, yet, although a patch is available for more than two years *sigh*).

signature.asc
Description: This is a digitally signed message part.

Bug#749330: systemd: The sysctl service is not started correctly at boot

[Patrick Häcker]

>> I guess the value dirty_writeback_centisecs defaults to 500. Other values
>> defined via sysctl have their (suspected) default value, too.
> 
> Which other values?

Values like 
> vm.dirty_background_bytes = 16777216
> vm.dirty_bytes = 100663296
which I have defined in sysctl.conf, too. Yet, the output of
> cat /proc/sys/vm/dirty_{background_,}bytes
is
> 0
> 0
which I assume to be default values. As mentioned: dirty_writeback_centisecs 
is only one example. Although, on closer examination, these three values seem 
to be the only one which are not applied, the other values defined in 
sysctl.conf are applied.
The pattern seems to be, that all values inside of "vm" get discarded and all 
the other values ("net", "fs" and "kernel" tested) are taken.

Okay, so my theory is void. I'll check your next e-mail, maybe that one can 
bring light into the dark.

Btw: Thanks for your patience!

signature.asc
Description: This is a digitally signed message part.

Bug#749330: systemd: The sysctl service is not started correctly at boot

[Patrick Häcker]

>>> vm.dirty_writeback_centisecs = 1500
>> which is used as an example to describe the bug in the following.
>> 
>> After boot,
>>> cat /proc/sys/vm/dirty_writeback_centisecs
>> returns
>> 500,
> 
> Do you use any power management tools, like acpi-support,
> laptop-mode-tools or pm-utils? If so, one of those might be setting that
> value on ac/battery changes.
acpi-support and laptop-mode-tools are not installed, but pm-utils is 
installed (version 1.4.1-14). A search through the results of
> grep 500 $(dpkg -S pm-utils | sed 's/^.* //')
does not give any plausible result

> I suspect laptop-mode-tools is the culprit:
> 
> http://sources.debian.net/src/laptop-mode-tools/1.64-1/usr/share/laptop-mode
> -tools/modules/laptop-mode?hl=418#L418
> 
> set_sysctl /proc/sys/vm/dirty_writeback_centisecs   "$U_AGE"
> 
> and
> 
> usr/share/laptop-mode-tools/modules/laptop-mode:  
U_AGE=$((100*$DEF_UPDATE))
> usr/sbin/laptop_mode:DEF_UPDATE=5
> 
> → there you have your 500
Thanks for your investigation, but as mentioned: laptop-mode-tools is not 
installed.

I guess the value dirty_writeback_centisecs defaults to 500. Other values 
defined via sysctl have their (suspected) default value, too, after boot and 
only change to the desired value after restarting the service manually as 
described. Thus, I guess that the sysctl service is not started correctly, 
although I cannot explain why systemctl should state otherwise (active, 
success) in this case.

signature.asc
Description: This is a digitally signed message part.

Bug#749330: systemd: The sysctl service is not started correctly at boot

[Patrick Häcker]

Package: systemd
Version: 208-1
Severity: normal

Dear Maintainer,

I have a file
> /etc/sysctl.d/98-save-power.conf
containing the line
> vm.dirty_writeback_centisecs = 1500
which is used as an example to describe the bug in the following.

After boot,
> cat /proc/sys/vm/dirty_writeback_centisecs
returns
> 500,
although
> systemctl status systemd-sysctl.service
returns
> systemd-sysctl.service - Apply Kernel Variables
>Loaded: loaded (/lib/systemd/system/systemd-sysctl.service; static)
>Active: active (exited) since Mo 2014-05-26 14:22:00 CEST; 4min 49s ago
>  Docs: man:systemd-sysctl.service(8)
>man:sysctl.d(5)
>   Process: 295 ExecStart=/lib/systemd/systemd-sysctl (code=exited, 
> status=0/SUCCESS)
>  Main PID: 295 (code=exited, status=0/SUCCESS)
> 
> Mai 26 14:22:00 mmm systemd[1]: Started Apply Kernel Variables.
> Mai 26 14:24:48 mmm systemd[1]: Started Apply Kernel Variables.
i.e. the service seems to be loaded correctly.

After manually executing
> systemctl restart systemd-sysctl.service
> cat /proc/sys/vm/dirty_writeback_centisecs
the result is
> 1500.

Executing
> systemctl status systemd-sysctl.service
again results in the same information as before (beside the dates)
> systemd-sysctl.service - Apply Kernel Variables
>Loaded: loaded (/lib/systemd/system/systemd-sysctl.service; static)
>Active: active (exited) since Mo 2014-05-26 14:27:27 CEST; 15s ago
>  Docs: man:systemd-sysctl.service(8)
>man:sysctl.d(5)
>   Process: 2531 ExecStart=/lib/systemd/systemd-sysctl (code=exited, 
> status=0/SUCCESS)
>  Main PID: 2531 (code=exited, status=0/SUCCESS)

I wasn't sure if this is a systemd problem, but as the printed status does not
change although the state of the system clearly changed, I do not have another
explanation.

Please note, that this problem also occured with versions 204-8 and 204-10. I
think it worked on some reboots, so a race condition might be involved, but I
cannot get it to work anymore during the last reboots, so this might be
incorrect.


-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl  2.2.52-1
ii  adduser  3.113+nmu3
ii  initscripts  2.88dsf-53
ii  libacl1  2.2.52-1
ii  libaudit11:2.3.6-1
ii  libblkid12.20.1-5.7
ii  libc62.18-7
ii  libcap2  1:2.22-1.2
ii  libcap2-bin  1:2.22-1.2
ii  libcryptsetup4   2:1.6.4-4
ii  libdbus-1-3  1.8.2-1
ii  libgcrypt11  1.5.3-4
ii  libkmod2 16-2
ii  liblzma5 5.1.1alpha+20120614-2
ii  libpam0g 1.1.8-3
ii  libselinux1  2.3-1
ii  libsystemd-daemon0   208-1
ii  libsystemd-journal0  208-1
ii  libsystemd-login0208-1
ii  libudev1 204-8
ii  libwrap0 7.6.q-25
ii  sysv-rc  2.88dsf-53
ii  udev 204-8
ii  util-linux   2.20.1-5.7

Versions of packages systemd recommends:
ii  libpam-systemd  208-1

Versions of packages systemd suggests:
pn  systemd-ui  

-- Configuration Files:
/etc/systemd/system.conf changed:
[Manager]
DefaultControllers=cpu memory blkio


-- no debconf information
[OVERRIDDEN] /etc/systemd/system/vsftpd.service → /lib/systemd/system/vsftpd.service

Files /lib/systemd/system/vsftpd.service and /etc/systemd/system/vsftpd.service are identical

[OVERRIDDEN] /run/systemd/system/session-1.scope.d/90-SendSIGHUP.conf → /run/systemd/system/session-c1.scope.d/90-SendSIGHUP.conf

Files /run/systemd/system/session-c1.scope.d/90-SendSIGHUP.conf and /run/systemd/system/session-1.scope.d/90-SendSIGHUP.conf are identical

[OVERRIDDEN] /run/systemd/system/session-1.scope.d/90-TimeoutStopUSec.conf → /run/systemd/system/session-c1.scope.d/90-TimeoutStopUSec.conf

Files /run/systemd/system/session-c1.scope.d/90-TimeoutStopUSec.conf and /run/systemd/system/session-1.scope.d/90-TimeoutStopUSec.conf are identical

[OVERRIDDEN] /run/systemd/system/session-1.scope.d/90-KillMode.conf → /run/systemd/system/session-c1.scope.d/90-KillMode.conf

Files /run/systemd/system/session-c1.scope.d/90-KillMode.conf and /run/systemd/system/session-1.scope.d/90-KillMode.conf are identical

[OVERRIDDEN] /run/systemd/system/session-1.scope.d/90-After-systemd-user-sessions\x2eservice.conf → /run/systemd/system/session-c1.scope.d/90-After-systemd-user-sessions\x2eservice.conf

Files /run/systemd/system/session-c1.scope.d/90-After-systemd-user-sessions\x2eservice.conf and /run/systemd/system/session-1.scope.d/90-After-systemd-user-sessions\x2eservice.conf are identical

[OVERRIDDEN] /run/systemd/system/session-1.scope.d

Bug#743813: pulseaudio: Pulseaudio logs an error when using KDE and systemd

[Patrick Häcker]

Package: pulseaudio
Version: 5.0-1
Severity: minor
Tags: patch

Dear Maintainer,

when using KDE and systemd (other combinations not tested), with every login
into KDE the following error gets logged for pulseaudio:

Daemon already running.

This is annoying when calling something like "journalctl -p 0..3".

The reason is probably the same as in
http://lists.opensuse.org/opensuse-bugs/2011-02/msg02096.html

The fix mentioned in answer 12 from user vjm at
https://bbs.archlinux.org/viewtopic.php?pid=1164699#p1164699
works for me (replacing the typo ":" by a ";" and ignoring the load-module
part).

Note, that even with this fix a login followed by a logout followed by
another login results in another logged error

module.c: Module "module-device-manager" should be loaded once at most.

but this is at least not the common case.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pulseaudio depends on:
ii  adduser   3.113+nmu3
ii  libasound21.0.27.2-3
ii  libasound2-plugins1.0.27-2+b1
ii  libc6 2.18-4
ii  libcap2   1:2.22-1.2
ii  libdbus-1-3   1.8.0-3
ii  libfftw3-single3  3.3.3-7
ii  libgcc1   1:4.8.2-16
ii  libice6   2:1.0.8-2
ii  libltdl7  2.4.2-1.7
ii  liborc-0.4-0  1:0.4.18-1
ii  libpulse0 5.0-1
ii  libsamplerate00.1.8-7
ii  libsm62:1.2.1-2
ii  libsndfile1   1.0.25-9
ii  libspeexdsp1  1.2~rc1.1-1
ii  libstdc++64.8.2-16
ii  libsystemd-login0 204-8
ii  libtdb1   1.2.13-1
ii  libudev1  204-8
ii  libwebrtc-audio-processing-0  0.1-2
ii  libx11-6  2:1.6.2-1
ii  libx11-xcb1   2:1.6.2-1
ii  libxcb1   1.10-2
ii  libxtst6  2:1.2.2-1
ii  lsb-base  4.1+Debian12
ii  udev  204-8

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  5.0-1
ii  rtkit  0.10-3

Versions of packages pulseaudio suggests:
pn  paman 
pn  paprefs   
pn  pavucontrol   
pn  pavumeter 
ii  pulseaudio-utils  5.0-1

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/start-pulseaudio-kde (from pulseaudio package)
debsums: changed file /usr/bin/start-pulseaudio-x11 (from pulseaudio package)


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

Bug#665720: iptables-persistent: unusable with systemd

[Patrick Häcker]

Forgot to mention in my last mail how to use it as an user:

systemctl daemon-reload
systemctl start iptables-persistent.service
systemctl enable iptables-persistent.service

The last line is used to have it activated in future boots.

signature.asc
Description: This is a digitally signed message part.

Bug#665720: iptables-persistent: unusable with systemd

[Patrick Häcker]

I added a small systemd unit file to avoid this bug. The unit file is 
unconventional, as it calls the shell script instead of replacing it. Note, 
that my experience with systemd is quite limited.

The systemd unit file contains the following:

[Unit]
Description=Loads iptables rules from /etc/iptables
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/init.d/iptables-persistent start

[Install]
WantedBy=multi-user.target


As a user you can save it as
/etc/systemd/system/iptables-persistent.service.
In the package, it should be saved as
/lib/systemd/system/iptables-persistent.service
instead.

signature.asc
Description: This is a digitally signed message part.

Bug#731072: closed by Theodore Ts'o (Re: Fwd: Bug#731072: linux-image-3.11-2-amd64: Mounting of small ext2 file systems fails on 3.11)

[Patrick Häcker]

Thanks a lot for this detailed analysis (my file has exactly the predicted 
size) and your suggestions for further improvements. Please apologize my wrong 
conclusion and your waste of time as a result. I try to do better in the 
future.

The question remains why the file system size and the physical size differed 
in the first place. I can't imagine what I could have done wrong when creating 
this file system to get such a difference (but my imagination is not always 
enough, as you have seen). Anyway, even if there was a bug once (I created it 
in September 2009) it does not occur anymore, as my tests lead to the same 
results as yours.

Thanks again for your great work!

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#731072: Fwd: Bug#731072: linux-image-3.11-2-amd64: Mounting of small ext2 file systems fails on 3.11

[Patrick Häcker]

Dear Ted,

as you probably have the best overview of the context of this bug (#731072),
I wanted to bring it to your attention.
I think it would be especially interesting to know if this is a known upstream 
problem (sooner or later other distributions should be affected as well), and 
what you think what the best solution to this problem is.

Cheers
Patrick

signature.asc
Description: This is a digitally signed message part.

Bug#731072: linux-image-3.11-2-amd64: Mounting of small ext2 file systems fails on 3.11

[Patrick Häcker]

Package: src:linux
Version: 3.11.8-1
Severity: normal

Dear Maintainer,

due to the changed kernel configuration to disable the ext2 module and
to enable
CONFIG_EXT4_USE_FOR_EXT23=y
the support for small ext2 file systems has been (accidently?) removed.
Small file systems here are file systems with less than 1024 blocks,
i.e. less than 1 to 4 MeBi depending on the block size. The change has
been introduced between 3.10 and 3.11 in Debian.

When trying to mount such a file system, the following error is printed:
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
>missing codepage or helper program, or other error
>In some cases useful info is found in syslog - try
>dmesg | tail  or so

The syslog contains the following line
> EXT4-fs (loop0): bad geometry: block count 1440 exceeds size of device (1048 
> blocks)

This information is not helpful. While the loss of support for small file
systems is unfortunate, I think the lack of information here is unacceptable.
Such small file systems are still being used, e.g. on removable media or in
the embedded world, thus the bug's severity can be critical for some users. 

I do not exactly know what the best fix of this bug is (and thus where to
assign this bug), but some solutions are:

- Revert the kernel configuration to support the ext2 module again
- Print a warning during kernel upgrade
- Print a precise error when mounting fails
- Support such small file systems with the ext4-for-ext2 config

For everyone else who is hit by this problem: As a workaround, an old Debian
kernel (3.10 or older) or a self-compiled kernel with separate ext2 support
can be used to recover the data on such file systems.
> mkfs.ext4 -b 1024 DEVICE
can be used to create an ext4 file system with a minimum size of 1 MeBi as an
alternative.

Cheers
Patrick


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

Bug#413291: Sometimes a workaround is possible

[Patrick Häcker]

Hi,

depending on your needs, you might be able to circumvent the problem by 
disabling the problematic buttons completely for imwheel.

I had problems with scrolling in konsole using the mouse wheel (scrolling 
downwards was too coarse) and with zooming in okular (zooming outwards while 
holding control and scrolling down with the mouse wheel did scroll the page 
instead of zooming) with the following configuration
> IMWHEEL_PARAMS='-b "4 5 6 7 8 9 10"'
in /etc/X11/imwheel/startup.conf.

This happened although I do not have the mouse wheel scroll down button 
configured in /etc/X11/imwheel/imwheelrc, as it contents only
> ".*"
> ,   Thumb1, Super_L|Shift_L|Tab
> ,   Thumb2, Super_L|Tab
> ,   ExtBt7, XF86Favorites
to switch through activities and activate the WorkFlow plasmoid.

As I did not need to modify the mouse wheel actions I deactivated them by 
setting
> IMWHEEL_PARAMS='-b "0 0 0 0 8 9 10"'
in startup.conf.

Due to that change, my scroll problems are solved. This is no general solution, 
but it might help some users until this is properly fixed.

Cheers
Patrick


signature.asc
Description: This is a digitally signed message part.

Bug#697056: wajig: Please add support for --solver option

[Patrick Häcker]

Package: wajig
Version: 2.7.3
Severity: wishlist

Dear Maintainer,

please add support for apt-get's --solver option, e.g., that you can write
wajig install --solver aspcud fish
instead of
su -c "apt-get install --solver aspcud fish"
(see 
http://www.dicosmo.org/MyOpinions/index.php/2012/05/24/122-using-external-solvers-with-apt-get-in-wheezy).

Thanks a lot.

Cheers
Patrick

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 
'stable-updates'), (400, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wajig depends on:
ii  apt  0.9.7.7
ii  aptitude 0.6.8.2-1
ii  dpkg 1.16.9
ii  python3  3.2.3-5
ii  python3-apt  0.8.8.1

wajig recommends no packages.

Versions of packages wajig suggests:
pn  alien  
pn  apt-file   
pn  apt-move   
ii  apt-show-versions  0.20
ii  dctrl-tools2.22.2
ii  debconf1.5.48
ii  deborphan  1.7.28.8
ii  debsums2.0.52
ii  dpkg-dev   1.16.9
ii  dpkg-repack1.37
ii  fakeroot   1.18.4-2
ii  locales2.13-37
pn  netselect-apt  
ii  reportbug  6.4.3
ii  sudo   1.8.5p2-1
ii  vrms   1.16

-- no debconf information


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

Bug#686250: vlc segfaults on opening a directory

[Patrick Häcker]

Hi,

I do not know if it is related, but here vlc sometimes (4 out of 10 times) 
segfaults when opening a directory from the command line, i.e. "vlc .". 

Valgrind complains about an "Unrecognised instruction", so it does not help 
so much.

This is the gdb output:
(gdb) run
Starting program: /usr/bin/vlc .
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
VLC media player 2.0.3 Twoflower (revision 2.0.2-93-g77aa89e)
[New Thread 0x7256a700 (LWP 2427)]
[New Thread 0x7fffecc27700 (LWP 2428)]
[0x605108] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. 
Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
[New Thread 0x7fffec71f700 (LWP 2429)]
[Thread 0x7fffecc27700 (LWP 2428) exited]
[New Thread 0x7fffecc27700 (LWP 2430)]
[Thread 0x7fffec71f700 (LWP 2429) exited]
[New Thread 0x7fffec71f700 (LWP 2431)]
libdvdnav: Using dvdnav version 4.2.0
libdvdread: Encrypted DVD support unavailable.

****
**  No css library available. See **
**  /usr/share/doc/libdvdread4/README.css **
**  for more information. **
****


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffec71f700 (LWP 2431)]
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
32  ../sysdeps/x86_64/multiarch/../strlen.S: Datei oder Verzeichnis 
nicht gefunden.
(gdb)

This is an amd64 system with testing (but I checked the version from 
unstable and the behavior is identical).

Cheers
Patrick


signature.asc
Description: This is a digitally signed message part.