Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)

[Martin Steigerwald]

Hi Tobias, hi Lorenzo.

Tobias, thanks for looking into this sponsoring request! I appreciate it.

Tobias Frost - 11.05.24, 10:24:31 CEST:
> On Tue, Apr 16, 2024 at 09:39:58AM +0200, Lorenzo wrote:
> > Control: block -1 by 1067525
> > 
> > this fix need to go to unstable because elogind 255.4.1 is already
> > there, but runit-services depends on runit > 2.1.2-56 (unstable is at
> > 2.1.2-54) so 1067525 needs to be uploaded first or together with this
> > one, otherwise runit-services is not installable
> 
> Ok, just saw that one.
> Please note that this fact must be stated in d/changelog, something like
> "Upload to unstable."

FWIW I run runit 2.1.2-59 and runit-services together with elogind 255.5-2 
on two Devuan Ceres systems with KDE's Plasma desktop. One I had patched 
manually, but I made sure the package version of the run dir for elogind 
was installed after the upgrade. The other one was upgraded regularly from 
elogind 252 and older runit / runit-services packages.

Runsvdir starts elogind correctly from the new path. I also reviewed the 
changes to the package for the updated path for elogind and I think they 
are correct. I am certainly no expert with runit, but as I contributed 
zcfan service dir at least I know something.

Devuan uses the upstream packages for runit, runit-services, dash, bash so 
I expect that runit-services 0.7.2 will work just fine on Debian, too. It 
would unbreak running elogind for runit users that did not patch their 
systems manually already. I bet most of them did by now, as many desktop 
environments do not work well, if at all, without some systemd-logind 
replacement. And the timeouts with login into a TTY or SSH session without 
some systemd-logind replacement are quite annoying as well. Sure we are 
still talking about a (small) minority of Debian users here.

Hope this helps regarding the review of the package and the sponsoring. In 
case any further changes need to be tested before upload, I am willing to 
do that.

Best,
-- 
Martin

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Hi Lorenzo.

Lorenzo - 11.05.24, 02:16:15 CEST:
> On Tue, 07 May 2024 15:08:37 +0200
> Martin Steigerwald  wrote:
> >[...]
> > Are init scripts supposed to be started with PATH variable set up and
> > exported or not? How is it done with SysVInit? I bet it would be best
> > to match as close as possible what SysVInit is doing to be as
> > compatible as possible.
> 
> I checked this and in sysvinit you don't have this bug because during
> boot sysvscripts are run via /etc/ini.d/rc script, and there is an
> 'export PATH' there. It could probably be triggered by calling the
> script directly during runtime.
> In runit we are calling scripts directly in stage1 so we have this bug

I see. 

> > Otherwise it might be challenging to chase and find all the corner
> > cases with existing setups. And as there is no issue initializing the
> > network in the container with SysVInit instead of Runit used as PID
> > 1, I'd consider a change in Runit. At least it could be challenging
> > to find whether networking inside a container is the only thing that
> > breaks.
> 
> I want to dig this further, I don't recall broken network under docker
> and I don't think is broken under qemu, but I can be wrong or remember
> something from before /etc/init.d/rc usage was dropped from stage1

Could have something to do with Incus / LXD then. I used Incus in Devuan 
testing (upcoming Excalibur), which is based on Debian testing (upcoming 
Trixie).

In case it is helpful for you I could post a step to step guide for a 
minimal Incus setup and/or at least some pointers.

> > > > I just wonder why stage 2 contains /usr/local bin directories. I
> > > > think that should not be the case. Shall I report this as a
> > > > different issue?
> > > 
> > > PATH is passed to env call for runsvdir, so I guess one can exec a
> > > bin from local as runscript (not sure) without setting the PATH. I
> > > can't think of other use cases..
[…]
> > Hmm, I get that. I am just a bit concerned as it may be a security
> > issue.
> 
> not urgent, but could you elaborate this (security implications)? is
> something like an attacker placing a modified foo in /usr/local/ that
> overrides the legit foo in /usr/bin or is something else? one still
> needs root privileges to write to /usr/local..

Good question. It is how I learned it. :)

Yes, usually /usr/local is only writable by root, however… maybe an admin 
or user with root privileges put some own version of say coreutils or 
whatever in there for whatever reason and forgot about it. And later on it 
has some security whole that remains unpatched. With

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:/usr/bin:/bin

a vulnerable command might be picked up from /usr/local's s(bin) as it is 
even before the regular system managed (s)bin directories.

Yes, you can consider that an user error, but there might even be other 
scenarios, like an user or admin installed some special version of ls or 
some other command in there as they prefer it. Even if the behavior or 
such a special replacement command is only slightly different than of the 
original system default command it could cause all kinds of trouble.

I believe this may be some of the reasoning behind the rule I learned 
about to only have system directories in PATH for system provided scripts 
and programs. It at least appears to me like the approach of least 
surprise. /usr/local, only root-writable or not, is user managed. There 
could be anything in there causing all kinds of various trouble.

A compromise here would be to change the path like this:

PATH=/usr/sbin:/sbin:/usr/bin:/bin:/usr/local/sbin:/usr/local/bin

With that order at least a modified "ls" from /usr/local/bin would not be 
picked up as there is a system managed one available. But a command that 
is not available in system managed directories would still be picked up 
from /usr/local directories.

As one point of practical experience, I changed path to

PATH=/sbin:/usr/sbin:/bin:/usr/bin

in one Incus managed Devuan container which runs a Wordpress blog on 
Apache and PHP FPM and I see no issues. However as I also don't have 
anything in /usr/local that is to be expected. One approach could be to 
just change the path to the above system managed directories only path, 
add some NEWS.Debian entry about it and see whether someone complains :)

I do think this discussion belongs into a different bug report though. I am 
willing to open a low priority report about this and include the previous 
relevant discussion to it, so it does not get lost and you can take your 
time to ponder about it. There is no need to rush it.

Have a great weekend!
-- 
Martin

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Hi Lorenzo.

Sorry for late answer.

Lorenzo - 14.04.24, 11:36:32 CEST:
> On Sat, 13 Apr 2024 15:05:41 +0200
> 
> Martin Steigerwald  wrote:
> > Martin Steigerwald - 13.04.24, 14:32:16 CEST:
> > > Any idea how to find the cause of what is happening here?
> > 
> > I found the cause:
> > 
> > The container starts out with an almost empty environment. In
> > [...]
> > 
> > root@zdevuan:~# cat rcS.log
> > 
> > >> environment
> > 
> > container=lxc
> > PWD=/
> > 
> > >> end of environment
> > 
> > No PATH defined.
> > 
> > The script defines it. See line 8 in my changed script. However it
> > 
> > does not export it. Thus adding line 9 fixes the bug I reported:
> >   8 PATH=/sbin:/usr/sbin:/bin:/usr/bin
> >   9 export PATH
> > 
> > The network is configured just fine after adding that line.
> >
> > Same goes for stage 2. In /etc/runit/2 I added:
> >[...]
> >
> > Exporting the PATH there as well like
> > 
> >   1 #!/bin/sh
> >   2
> >   3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
> >   4 export PATH
> >   5 SVDIR=/etc/service
> > 
> > fixes
> > 
> > root@zdevuan:~# cat /etc/boot.d/network
> > #!/usr/bin/env sh
> > 
> > /etc/init.d/networking restart
> > 
> > The network is configured even without the "export PATH" fix in
> > /etc/runit/1.
> 
> OK, so if I undertand correctly we either export PATH in the
> /etc/init.d/networking script or we export PATH both in stage 1 and 2
> (so the script does not fail during boot and can be called during
> runtime): is that correct?

In case it is called during both stage 1 and stage 2, yes. And yes, it 
appears there is a link to the networking script in /etc/rcS.d which would 
be called in stage 1.

> If yes I think it's better to fix the networking script (ifupdown pkg)
> so that the fix works for sysvinit users too.

Yeah, I would think so to, but:

% grep PATH /etc/init.d/networking
PATH="/sbin:/bin:/usr/sbin:/usr/bin"

Yet, it has no export statement, it just defines the variable.

What may be happening here is that something called from the script 
requires a valid path, but without export the variable would not be 
exported to that something.

So it might be that the networking script needs an "export PATH" added to 
it.

However:

> Different story if multiple scripts fails during boot because of empty
> PATH; many scripts in /etc/rc.S/ set their PATH but others don't..
> Could you confirm that no other scripts fails in your container setup
> when PATH is not exported in stage 1 ?

There are some script which do not set a command search path:

% grep -L "PATH" *
README
brightness
checkroot-bootclean.sh
hwclock.sh
mariadb
mountall-bootclean.sh
mountnfs-bootclean.sh
mountnfs.sh
procps
rcS
sudo

I am not sure whether those work correctly or not. Some are not even 
supposed to work inside a container at all.

What I wonder: What is the supposed default or standard here?

Are init scripts supposed to be started with PATH variable set up and 
exported or not? How is it done with SysVInit? I bet it would be best to 
match as close as possible what SysVInit is doing to be as compatible as 
possible.

Otherwise it might be challenging to chase and find all the corner cases 
with existing setups. And as there is no issue initializing the network in 
the container with SysVInit instead of Runit used as PID 1, I'd consider a 
change in Runit. At least it could be challenging to find whether 
networking inside a container is the only thing that breaks.

Of course in case PATH variable needs to be setup, one might argue that 
Incus/LXC needs to do it, cause networking is setup just fine even with 
Runit in physical machines or VMs.

So far the container appears to be working, but I did not check whether 
every single init script works correctly. Partly due to bootlogd not 
working inside the container.

> > I just wonder why stage 2 contains /usr/local bin directories. I think
> > that should not be the case. Shall I report this as a different issue?
> 
> PATH is passed to env call for runsvdir, so I guess one can exec a bin
> from local as runscript (not sure) without setting the PATH. I can't
> think of other use cases..
> I'm fine with removing, just a bit wary, I'm afraid to break some custom
> setup

Hmm, I get that. I am just a bit concerned as it may be a security issue.

> > I added empty "debug" and "verbose" files in /etc/runit but did not
> > find any debug output. Maybe those files needed to have some content.
> > Maybe it requires bootlogd.
> 
> those files only work for runit stuff (runscripts and the sv trigger),
> boot scripts are for sysvinit and do not obey to runit settings :(
> perhaps it's time to roll some native runit bootscripts..

I see. Well that would be great. But also would require a lot of work and 
testing I bet.

Best,
-- 
Martin

Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0

[Martin Steigerwald]

Martin Steigerwald - 02.05.24, 16:43:28 CEST:
> Work-around for affected users:

Of course this work-around is no longer necessary.

Thank you for the quick fix, Laszlo. I appreciate it.

-- 
Martin

Bug#1070217: chromium: Symbol lookup error with libsnappy1v5>=1.2.0

[Martin Steigerwald]

Work-around for affected users:

Download and install

libsnappy1v5_1.1.10-1+b1_amd64.deb

from

https://snapshot.debian.org/archive/debian/20240210T223313Z/pool/main/s/snappy/


Temporary protection:

% cat /etc/apt/preferences.d/libsnappy 
Explanation: Debian#1070217: chromium: Symbol lookup error with 
libsnappy1v5>=1.2.0
Explanation: https://bugs.debian.org/1070217
Package: libsnappy1v5
Pin: version *
Pin-Priority: -3

Please remove once bug is fixed.

Thanks,
-- 
Martin

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Martin Steigerwald - 13.04.24, 15:05:41 CEST:
> No PATH defined.
> 
> The script defines it. See line 8 in my changed script. However it does
> not export it. Thus adding line 9 fixes the bug I reported:
> 
>   8 PATH=/sbin:/usr/sbin:/bin:/usr/bin
>   9 export PATH
> 
> The network is configured just fine after adding that line.

Since configuring networking works on physical machines – I know for sure 
with Devuan 5 aka Daedalus and Devuan Ceres which was at a similar state 
Devuan Excalibur is currently – regarding the right fix the question 
remains:

What is different with the PATH in both cases and why?

Why is it empty inside the (unprivileged) Incus managed LXC container? Is 
it empty on the physical machine? I doubt it. But where does the difference 
come from? And anyway the PATH is being set in both stage 1 and stage 2 
scripts, just not exported. So on a physical machine it appears that PATH 
is being exported before already. It might be exported before already on a 
container as well, albeit undefined / empty.

In both cases /bin/sh points to /bin/dash. Both the VM with Excalibur and 
the physical host with Daedalus are usrmerge'd.

-- 
Martin

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Martin Steigerwald - 13.04.24, 14:32:16 CEST:
> Any idea how to find the cause of what is happening here?

I found the cause:

The container starts out with an almost empty environment. In
/etc/runit/1 I added lines 4 to 6:

  1 #!/bin/sh
  2 # system one time initialization tasks
  3 
  4 echo ">> environment" >> /tmp/rcS.log
  5 /usr/bin/env >> /tmp/rcS.log
  6 echo ">> end of environment" >> /tmp/rcS.log
  7 
  8 PATH=/sbin:/usr/sbin:/bin:/usr/bin

(For some reason using /tmp/rcS.log did not give me any output. Although
/tmp is not mounted elsewhere during the boot process.)

This gives me:

root@zdevuan:~# cat rcS.log 
>> environment
container=lxc
PWD=/
>> end of environment

No PATH defined.

The script defines it. See line 8 in my changed script. However it does not 
export it. Thus adding line 9 fixes the bug I reported:

  8 PATH=/sbin:/usr/sbin:/bin:/usr/bin
  9 export PATH

The network is configured just fine after adding that line.



Same goes for stage 2. In /etc/runit/2 I added:

 38 echo "$runsv_dir" 2>&1 >> /tmp/rc2.log
 39 echo ">> environment" >> /tmp/rc2.log
 40 env >> /tmp/rc2.log >>  /tmp/rc2.log
 41 echo ">> end of environment"
 42 ls -l /etc/runit/no.emulate.sysv 2>&1 >>/tmp/rc2.log
 43 if [ "$runsv_dir" != solo ] && [ ! -e /etc/runit/
no.emulate.sysv ]; then
 44 echo "run rc2.d scripts…" 2>&1 >>/tmp/rc2.log
 45 /lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d' 2>&1 >>/tmp/rc2.log
 46 fi

Which gives me:

>> environment
container=lxc
PWD=/
>> end of environment

Exporting the PATH there as well like

  1 #!/bin/sh
  2 
  3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
  4 export PATH
  5 SVDIR=/etc/service

fixes

root@zdevuan:~# cat /etc/boot.d/network
#!/usr/bin/env sh

/etc/init.d/networking restart

The network is configured even without the "export PATH" fix in
/etc/runit/1.

I just wonder why stage 2 contains /usr/local bin directories. I think
that should not be the case. Shall I report this as a different issue?



I am now undoing my debug output.

I think I could provide a merge request for the fixes at a later time.
For now I like to finish the Devuan template and actually use it.

That bootlogd does not seem to work inside a container is a different
issue I may report at another time.

I added empty "debug" and "verbose" files in /etc/runit but did not
find any debug output. Maybe those files needed to have some content.
Maybe it requires bootlogd.

But that is for another time :)

Best,
-- 
Martin

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Package: runit-init
Version: 2.1.2-54
Severity: normal
X-Debbugs-Cc: mar...@lichtvoll.de

Dear Maintainer,

Hi!

I have Devuan Excalibur with Incus (forked from LXD) managed LXC
containers. reportbug said the package is unforked and thus I agreed
to send to Debian BTS instead.

All but one of them are Alpine Linux. In there I installed dhcpcd for
dual stack DHCP from Incus managed dnsmasq.

I am currently configuring myself a Devuan template starting from

incus launch images:devuan/daedalus zdevuan

I installed runit-init and socklog-run in there.

The containers comes up but dhcpcd is not running.

It should have been started by /etc/init.d/networking due to
/etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

And indeed it is:

root@zdevuan:~# /etc/init.d/networking start
Configuring network interfaces...dhcpcd-9.4.1 starting
[…]

However even with:

root@zdevuan:~# cat /etc/boot.d/network
#!/usr/bin/env sh

/etc/init.d/networking start

it does not work.



I looked up how runit stage 2 runs init scripts. It does so by:

root@zdevuan:/etc# grep -r "rc2.d"
runit/2:/lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d'

So I ran

/lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d'

manually and indeed it picks up /etc/boot.d/network:

root@zdevuan:~# /lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d'
dmesg: read kernel buffer failed: Operation not permitted
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
Configuring network interfaces...dhcpcd-9.4.1 starting
[…]

That last line is from /etc/boot.d/network.

Thus I tried to find out whether /etc/runit/2 actually runs those scripts
on boot:

 38 echo "$runsv_dir" 2>&1 >> /tmp/rc2.log
 39 ls -l /etc/runit/no.emulate.sysv 2>&1 >>/tmp/rc2.log
 40 if [ "$runsv_dir" != solo ] && [ ! -e /etc/runit/no.emulate.sysv ]; 
then
 41 echo "run rc2.d scripts…" 2>&1 >>/tmp/rc2.log
 42 /lib/runit/async-timeout /lib/runit/run_sysv_scripts 
'/etc/rc2.d' 2>&1 >>/tmp/rc2.log
 43 fi

This gives me:

root@zdevuan:~# cat /tmp/rc2.log 
default
run rc2.d scripts…
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
Configuring network interfaces...failed.

So indeed stage 2 runs the scripts. But it cannot configure the network
interface at this time. However running

/lib/runit/async-timeout /lib/runit/run_sysv_scripts '/etc/rc2.d'

later just works okay as shown above.

Also putting "/etc/init.d/networking restart" inside
"/etc/boot.d/network" does not work:

Running /etc/init.d/networking restart is deprecated because it may not 
re-enable some interfaces ... (warning).
Reconfiguring network interfaces...failed.

Not even putting

echo "ifdown eth0:"
ifdown eth0

echo "ifup eth0:"
ifup eth0

in there does work:

root@zdevuan:~# cat /tmp/rc2.log 
default
run rc2.d scripts…
Not running dhcpcd because /etc/network/interfaces ... failed!
defines some interfaces that will use a DHCP client ... failed!
ifdown eth0:
ifup eth0:

No output from "ifup eth0" which does not seem right.

However "ifdown eth0" and "ifup eth0" just works fine after booting. But
even if I insert a "sleep 10" before those, it still does not work.



I also looked for how rcS.d scripts are executed by Runit stage 0:

root@zdevuan:/etc# grep -r "rcS.d"
[…]
runit/1:for script in /etc/rcS.d/S* ; do


In there I added for debugging:

 11 for script in /etc/rcS.d/S* ; do
 12 path=$(realpath "$script")
 13 name=${path##*/}
 14 [ -e "/etc/runit/no.emulate.sysv.d/$name" ] && continue
[…]
 19 echo "run $script" >>/tmp/rcS.log
 20 "$script" start --force-sysv 2>&1 >>/tmp/rcS.log
 21 done

And indeed stage1 runs the scripts. But configuring network interfaces
fails there as well:

root@zdevuan:~# cat /tmp/rcS.log 
run /etc/rcS.d/S08mountall.sh
Mounting local filesystems...done.
Activating swapfile swap, if any...done.
run /etc/rcS.d/S09mountall-bootclean.sh
Cleaning up temporary files
run /etc/rcS.d/S10brightness
run /etc/rcS.d/S10procps
Starting Setting kernel variables: sysctl is already running.
run /etc/rcS.d/S10stop-bootlogd-single
run /etc/rcS.d/S10urandom
run /etc/rcS.d/S11networking
Configuring network interfaces...failed.
run /etc/rcS.d/S12mountnfs.sh
run /etc/rcS.d/S13mountnfs-bootclean.sh
Cleaning up temporary files
run /etc/rcS.d/S14bootmisc.sh


However as bootlogd is not being started and would not work inside
an LXC container anyway, I am not sure I can see any logging:

root@zdevuan:~# /etc/init.d/bootlogd start
Starting boot logger: bootlogdbootlogd: ioctl(/dev/pts/2, TIOCCONS): Operation 
not permitted


Any idea how to find the cause of what is happening here?

Best,
-- 
Martin

-- System Information:
Devuan Release: 

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Martin Steigerwald]

Martin Steigerwald - 13.02.24, 00:24:35 CET:
> This breaks compiling my own kernel with:
> 
> time eatmydata make -j16 bindeb-pkg LOCALVERSION=-t14

Work-around:

[…]etc/apt/preferences.d% cat kmod 
Explanation: Bug #1063804: FTBFS: depmod: FATAL: could not search modules: No 
such file or directory
Package: kmod libkmod2
Pin: version *
Pin-Priority: -3

Install kmod and libkmod2 31-1 from snapshot.debian.org.

Best,
-- 
Martin

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Martin Steigerwald]

Hi!

This breaks compiling my own kernel with:

time eatmydata make -j16 bindeb-pkg LOCALVERSION=-t14

Likely going to downgrade and pin kmod to a working version as I am 
seriously fed up with usr-merge related bugs. (Yeah, it is called unstable 
for a reason and if I use it unstable is what I may get. But I really 
don't see how any possible benefit justifies that immense and error-prone 
effort. Anyway it is not me doing that work.)

Best,
-- 
Martin

Bug#1061728: fio: add build support for loongarch64

[Martin Steigerwald]

Hi Dandan.

Thanks for your in-advance notice.

Am Montag, dem 29.01.2024 um 15:57 +0800 schrieb zhangdandan:
> Maybe we need to add build support for loongarch64.
> I hope to give you feedback in advance.
> Please consider the patch I have attached.
>
> I would like to remind you that the compilation dependency of fio is
> not yet satisfied. Depends on the librbd-dev and libnbd-dev packages
> when compiling fio.

So about timing: Does it make sense to include your patch in the next
upload already or do you prefer me to wait until further notice?

I intend to wait for next fio release until uploading again.

Ciao,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Jonas Hasselberg
 •
Chris Hudson
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#1059937: fio: FTBFS on riscv64: tries to uses rdcycle, privileged since kernel 6.6

[Martin Steigerwald]

Thanks for the bug report, Aurelien.

Am Mittwoch, dem 03.01.2024 um 22:45 +0100 schrieb Aurelien Jarno:
> Since the build daemons have been upgraded to kernel 6.6, fio FTBFS
> with SIGILL in the testsuite. It is because the rdcycle instruction
> has been changed to a privileged instruction starting with this kernel
> version.
>
> A fix is available in the upstream repository [1]. Would it be
> possible to include it in the next upload?

Sure. Instead of maintaining a patch for one version of fio and then
removing it again however I prefer to wait for the next version of fio
before the next upload.

Feel free to ping upstream about a new release.

In case this is more urgent for you, feel free to provide a merge
request on Salsa.

Thanks,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Jonas Hasselberg
 •
Chris Hudson
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#1057295: bcachefs-tools: breaks "mount" if the package is installed

[Martin Steigerwald]

Hi Jonathan, hi Adam!

Confirmed.

Moving "mount.bcachefs" out of the way fixes mounting via "fstab" and 
"mount" command. It also makes mounting work on boot with Devuan with 
Runit as init.

Help output of "bcachefs" command from self-compiled bcachefs-tools 1.3.3 
shows:

Mount:
  mountMount a filesystem

This is missing from the help output of "bcachefs" command, version 1.3.4, 
from the package.

Best,
-- 
Martin

Bug#1053167: Please remove librbd-dev build-depends on 32 bits arch

[Martin Steigerwald]

Hi Thomas.

Am Donnerstag, dem 28.09.2023 um 16:38 +0200 schrieb Thomas Goirand:
> So please remove librbd-dev in build-depends of your package for all
> 32 bits arch, and remove Ceph support in all 32 bits binaries. I'll
> upload Ceph with Build-Depends: architecture-is-64-bit as soon as this
> is done
> for the 4 affected packages:
> - fio
> - libvirt
> - tcmu
> - qemu

I am quite busy.

First day I can possibly look into that is next Wednesday. I hope I
manage to get to it on that day. If you like you can provide a merge
request on Salsa, but as it is a minor change I should be able to get to
it next Wednesday as long as I have a little time slot for it.

Ciao,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Jonas Hasselberg
 •
Chris Hudson
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#967339: fio: depends on deprecated GTK 2

[Martin Steigerwald]

Hi Bastian.

Am Samstag, dem 12.08.2023 um 14:08 +0200 schrieb Bastian Germann:
> Please remove the gfio package from Debian. I do not think anyboy will
> port to a newer gtk version.

Thanks for your merge request! I applied it and asked my sponsor to
upload.

Best,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#967339: fio: depends on deprecated GTK 2

[Martin Steigerwald]

Hi Bastian,

Am Samstag, dem 12.08.2023 um 14:08 +0200 schrieb Bastian Germann:
> Please remove the gfio package from Debian. I do not think anyboy will
> port to a newer gtk version.

I am aware of the answer from Jens Axboe.

Will remove gfio package once as I manage to take time for it. Feel free
to provide a merge request on Salsa.

Thanks,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#1051471: btrfsd: cron job for calling btrfsd

[Martin Steigerwald]

Hi Matthias.

Thanks for your kind and detailed feedback. As next releases are quite a 
bit away, there is no need to rush anything here. CC'ing the Debian init 
diversity mailing list as to gather additional feedback on whether my 
ideas about how to proceed make sense:

Matthias Klumpp - 10.09.23, 00:15:07 CEST:
> Am Fr., 8. Sept. 2023 um 15:24 Uhr schrieb Martin :
> > [...]
> > would you consider to include a cron job into the package in order to
> > make btrfsd installable on systems without Systemd? Of course a change
> > regarding package dedepencies would also be required.
> 
> Sure, that should actually be extremely low-maintenance, there isn't
> any hard dependency the daemon has on systemd - with one exception: It
> uses libsystemd to write to the journal if that's available, and I
> would like to keep that feature. It will however already fall back to
> syslog in case sd-journal isn't available, and libsystemd is inert on
> systems without systemd.

As far as I see on my Devuan system there is libelogin-compat which 
replaces and provides libsystemd0. So I think a dependency on libsystemd0 
would be resolved by having libelogin-compat installed.

However this one is not available on Debian. But while here on Devuan 
installing libsystemd0 directly would remove most of my Plasma desktop, I 
bet on Debian libsystemd0 can be installed without systemd package being 
installed as well. AFAIK util-linux on Debian depends on libsystemd0 for 
example while on Devuan it does not. Any feedback from people using other 
than Systemd init on Debian? Do you have libsystemd0 installed?

I am willing to test whether a btrfsd package with cron job and Systemd 
timer would be installable on Devuan, Debian with Systemd and Debian 
without Systemd. I can do so with my laptop and two VMs.

However for systems without Systemd I bet the hard dependency on "systemd" 
package itself would have to be replaced by something else. I wonder: Is a 
hard dependency on "systemd" package required in case the package also 
provides a cron job in addition to the Systemd timer?

> > I have seen btrfsd in mailing list "debian-devel-changes" but could
> > not find it on my Devuan system.
> > 
> > If yes, I would aim to provide a merge request.
> 
> This could go upstream, I think.
> I do not know if there is a no-overhead way to ship both the cron job
> and systemd timer in the same package with recompilation. But if
> that's not possible, I think at the very least we could provide a
> configuration option upstream to select one or the other, so
> derivatives that don't use systemd could switch to the cron version by
> simply recompiling the package (by checking dpkg vendor strings).

If for example depending on libsystemd0 would be a problem in Devuan it 
would still be preferable to have as much as possible in upstream package, 
so that the diff to be applied to make btrfsd package work on Devuan is as 
small as possible. Of course I'd aim to make btrfsd package usable on 
Debian without Systemd as well, so that there is a benefit for Debian users 
as well.

> What do you think? Unfortunately I know little how to make both
> systems interoperate and avoid having the timer and cron job calling
> the service, so patches would be very welcome.

I'd aim at providing a merge request proposal after gathering enough 
feedback on how to do it properly. I have seen cron jobs checking for 
presence of Systemd and only running in case Systemd is not installed, 
cause otherwise the Systemd timer would do the job. I don't know in which 
package, but I am confident I can find it again. AFAIR the check was pretty 
straight forward.

To people from debian-init-diversity mailing list: Do you have any 
examples of this working? If so, please kindly advice on where to find 
those. Would be nice to be able to at least partly copy an approach that 
has proven itself to work okay.

Best,
-- 
Martin

Bug#1042082: Please take over udev SysV init script

[Martin Steigerwald]

Matthew Vernon - 26.07.23, 21:22:15 CEST:
> > may I suggest to add this script to initscripts
> > package(sysvinit:src) instead of o-s-s?
> > A system without udev is not very common after all and the vast
> > majority of scripts strictly needed to boot and shutdown the system
> > are shipped there.
> 
> Wearing my o-s-s maintainer hat, I have no problem with this suggest -
> what do the sysvinit maintainers think?
> 
> [though I suspect we are going to end up with o-s-s being a dependency
> of sysvinit-core at this rate]

How about using a similar approach than with the runit-services package?

Make a sysvinit-services package or better rename orphan-sysvinit-
scripts to that name and make it a dependency? Well runit-services is 
just a recommend to runit-init… but in case of udev… a dependency would 
be better. Of course it could also remain named orphan-sysvinit-scripts

Also a missing udev init script could affect users running runit as well. 
runit-services currently has no runit service dir to start udev. So 
runit would rely on the init script.

-- 
Martin

Bug#1041703: Broken due to missed udev dependencies

[Martin Steigerwald]

Simon McVittie - 22.07.23, 18:01:22 CEST:
> On Sat, 22 Jul 2023 at 13:57:33 +0100, Klaus Ethgen wrote:
[…]
> > ii  libeudev1 [libudev1]  3.2.12-1
> 
> libeudev1 is not part of Debian. If it was, I'd be reassigning this
> bug to libeudev1; but it isn't, so I'm closing the bug instead.
> Please report this to wherever you obtained your libeudev1 package
> from.

I was not aware that eudev is not part of Debian.

Fair enough. Thanks.

-- 
Martin

Bug#1041703: Broken due to missed udev dependencies

[Martin Steigerwald]

Martin Steigerwald - 22.07.23, 16:06:11 CEST:
> Ah and I see Klaus is using eudev. Thus lowering bug severity again.

So this bug should probably be reassigned to eudev?

-- 
Martin

Bug#1041703: Broken due to missed udev dependencies

[Martin Steigerwald]

severity 1041703 important
thanks

Martin Steigerwald - 22.07.23, 15:41:41 CEST:
> severity 1041703 grave
> thanks
> 
> Justification: Renders X unusable, renders fwupdmgr unusable

On the other hand Sid should have libudev1 254~rc2-3. Even testing 
should have 253.5-1 already.

Ah and I see Klaus is using eudev. Thus lowering bug severity again.

-- 
Martin

Bug#1041703: Broken due to missed udev dependencies

[Martin Steigerwald]

Working package for AMD64:

https://ftp.debian.org/debian/pool/main/libg/libgudev/libgudev-1.0-0_237-2_amd64.deb

-- 
Martin

Bug#1041703: Broken due to missed udev dependencies

[Martin Steigerwald]

severity 1041703 grave
thanks

Justification: Renders X unusable, renders fwupdmgr unusable

Probably also breaks xdg-desktop-portal file dialog when clicking on a 
mount point from an USB connected external device. Maybe some other 
crashes I experienced in the running Plasma session before reporting 
after the update have been related to this.

Did not test whether it would break input in Wayland session.

Also at least "serious" is necessary to warn people who use apt-listbugs 
about the bug. I'd not have had a broken system in case apt-listbugs 
would have warned me. (I know it is called unstable for a reason). One 
can argue whether "serious", "grave" or even "critical" would be most 
appropriate, as the wording regarding the severity levels leaves some 
room for interpretation, but I am convinced that important is not severe 
enough.

AFAIK at least "serious" is necessary to prevent the package from 
entering "testing".

I confirm that downgrading to libgudev-1.0-0 237-2 fixes the issue.

Best,
-- 
Martin

Bug#1041552: HFS/HFS+ are insecure

[Martin Steigerwald]

Hi Marco, hi,

Marco d'Itri - 21.07.23, 10:55:39 CEST:
> On Jul 21, Matthew Garrett  wrote:
> > > You are totally correct.
> > > Kernel team, please blacklist HFS/HFS+ for automounting.
> > 
> > Isn't this a userland policy decision? udisks will happily trigger a
> > module load for hfsplus if udev has identified it, and I don't think
> > there's a trivial mechanism for the kernel to disable that. I
> > believe
> 
> Yes, I was also thinking about this and I believe that you are right.
> The kernel team did this in the past for some uncommon network
> protocols, but they could do it themselves because these modules are
> autoloaded using aliases.
> 
> Since I happen to be the kmod maintainer it looks like that solving
> this is on me. :-)
> 
> Unless somebody has a better idea then then my plan is to ship in the
> next upload of kmod a file in /etc/modprobe.d/ which uses the
> blacklist directive to prevent automatically loading some file system
> modules.
[…]
> I think that all of these have enough of a niche usage that it would
> not be an unreasonable burden for the affected users to manually load
> the modules when needed (ad hoc or using /etc/modules-load.d/).

In case you do this, I'd like there to be a NEWS.Debian entry about 
this, explaining both the justification behind it and how people can work 
around it. It could go like this:

---

Since version xyz of kmod the file /etc/modprobe.d/block-unsafe-
filesystems.conf prevents loading of several filesystem modules that are 
automatically loaded by udev when inserting a medium that contains one 
of them. These filesystems are either known to be unsafe or are not 
maintained actively anymore. A deliberately corrupted filesystem 
structure could trigger the filesystem driver in the module to crash, 
corrupt memory of other kernel components or to cause other problems. 
[Adjust to whatever risks are most likely to occur] [Add some links here 
for the discussion about that]

In case you rely on using one or more of these filesystems you can either 
edit the file /etc/modprobe.d/block-unsafe-filesystems.conf and put a 
comment sign before the filesystem in question or add the filesystem to a 
file to a file in /etc/modules-load.d/. [Please clarify here as needed]

Please take care not to plug in any device that you do not trust.

---

This is just a rough idea it probably needs several iterations to obtain 
a good wording that balances on assessing the risk correctly (without 
over or under estimating it). Also the method of circumventing the 
blocking may need further explanations. I am not using systemd, so I can 
not describe exactly how modules-load.d works. In case you like to use 
any of the above wording, feel free to use it under the license of the 
packaging of kmod.


I wonder about other kernel modules in other areas of the kernel that 
may be automatically loaded when connecting some hardware… especially 
some random USB device, but… that appears to me like opening a huge can 
of worms. I bet the Linux kernel has more than several hundreds of 
specialized USB drivers maybe even more than thousand meanwhile despite 
all the USB standards out there?

Linux is not a micro kernel. It was not designed to run drivers in a 
restricted and (somewhat) safe environment to begin with. That means 
ideally you'd have to audit all the drivers for security issues 
regularly or at least after a certain amount of changes made to it. In 
case you do not, for some random driver it will be difficult to know for 
sure whether it is safe or unsafe to use. Maybe some small filesystem 
driver like affs that still receives a patch every now and then is safer 
to use than the much more complex BTRFS filesystem driver.¹ Who knows? Of 
cause some fuzzing may really help. But it is not a guarantee either.

And then what about other kernel functionally that is loaded as module 
on demand that is only rarely used by some people?

So I wonder what body of evidence there is to base a policy decision on 
which driver to load or not to load automatically. Without a reliable 
body of evidence there is always the risk to either over or under policy 
the users of Debian and derived distributions (whose maintainers do not 
decide to change such a policy decision again). So I'd argue against 
taking the quick route on that to allow the time for a more informed 
decision. Maybe start with clear-cut cases likely probably HFS/HFS+ 
instead of just adding all kinds of other filesystems without even know 
whether there is a known exploit. Of course you could go by maintenance 
status, however, this can be inaccurate. How to do accurately determine 
maintenance status, especially as MAINTAINERS file may not be accurate or 
up-to-date at all times? And how many specialized USB drivers are there 
that are compiled as modules on Debian kernels that may not 

Bug#1032368: bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

[Martin Steigerwald]

Mark Hindley - 06.03.23, 17:22:12 CET:
> On Mon, Mar 06, 2023 at 03:25:18PM +, Simon McVittie wrote:
> > What I absolutely don't want is to make the change, and then 2 years
> > later get hate mail from someone telling me that I've broken their
> > system by making dbus-launch prevent /home from being unmounted and
> > "why can't you just" add an option to use daemon(3).
> 
> I think that is a very good point.

I have thought about this some more and the following question came up: 
Why would dbus-launch with $HOME as current working directory prevent 
from unmounting /home any more than any other process that runs with a 
user session? At least with desktop environments like Plasma and GNOME 
there is a ton of other processes blocking unmounting /home. It could be 
with a very limited environment like with a tiling window manager that 
nothing else would be using $HOME as working directory, but that must be 
a very limited environment then, I'd say. Anyway: There will be no hate 
mail from me. Promised.

I did some more testing which in the end is just a confirmation of what I 
could have known already from the previous discussion. While I did not 
confirm the PID of the dbus-launch process started by the "75dbus_dbus-
launch" script it also pretty much confirms that the session DBUS is 
started by that script.

I added

date >/tmp/dbus-launch-started
echo $HOME >/tmp/dbus-launch-home
pwd >/tmp/dbus-launch-pwd

to "/etc/X11/Xsession.d/75dbus_dbus-launch" and

date >/tmp/dbus-update-env-started
echo $HOME >/tmp/dbus-update-env-home
pwd >/tmp/dbus-update-env-pwd

to "/etc/X11/Xsession.d/95dbus_update-activation-env".

And got this:

% grep . /tmp/dbus-launch-*
/tmp/dbus-launch-home:/home/martin
/tmp/dbus-launch-pwd:/home/martin
/tmp/dbus-launch-started:Di 7. Mär 18:02:12 CET 2023

% grep . /tmp/dbus-update-env-*
/tmp/dbus-update-env-home:/home/martin
/tmp/dbus-update-env-pwd:/home/martin
/tmp/dbus-update-env-started:Di 7. Mär 18:02:12 CET 2023

So both are started and both have the right working directory and $HOME 
set to the user starting the X session.

So it is really that chdir("/") in dbus-launch¹ that causes the issue at 
hand and thus there is no way to globally work-around the issue I 
reported, at least not short of recompiling dbus-launch without that 
chdir in place. Actually that is the result that was to be expected. But 
now I confirmed it. I'd wonder that anyone who would really like to have 
the option to have "dbus-launch" as started by "75dbus_dbus-launch" 
having "/" as current working directory could just change the script, 
given the chdir("/") would be patched out of dbus-launch.

[1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

Interestingly in "/etc/X11/Xsession.d/95dbus_update-activation-env" 
there is:

  # Note that anything that is D-Bus-activated between here and
  # 95dbus_update-activation-env will not have the complete environment
  # set up by Xsession.d, unless the Xsession.d snippet that sets the
  # environment variable also calls dbus-update-activation-environment.
  # See 

but there are only "90gpg-agent" and "90x11-common_ssh-agent" between 
it. So it seems to be whatever "95dbus_update-activation-env" is doing 
does not including telling dbus-launch to switch working directory to 
$HOME. But at least with anything started through krunner $HOME is set 
correctly to the users home directory.

> KDE is the only area where I have heard of this causing problems and I
> am not aware of any other reports that seem to have the same
> underlying cause. I am not convinced there *is* a consensus for
> change and the risk of changing the default for all users of legacy
> DBus activation seems high.
> 
> Martin, I still think this is for KDE to address if it is important to
> them. I don't think I would push to change the behaviour of DBus in
> either Debian or Devuan at the moment.

So I really hope that KDE developers are willing to make a change. Of 
course they could argue, that it worked before…

Until then I have a workaround for KRunner (a desktop file in Autostart) 
and also one for XDG KDE portal.

It appears to me that in

% cat /usr/share/dbus-1/services/
org.freedesktop.impl.portal.desktop.kde.service
[D-BUS Service]
Name=org.freedesktop.impl.portal.desktop.kde
Exec=/usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
SystemdService=plasma-xdg-desktop-portal-kde.service

as well as

% cat /usr/share/dbus-1/services/org.kde.krunner.service
[D-BUS Service]
Name=org.kde.krunner
Exec=/usr/bin/krunner
SystemdService=plasma-krunner.service

there is no provision to change the working directory for the started 
DBUS service. At least I found no documentation of the specification of 
those DBUS service files.

Something like

sh -c "cd $HOME; /usr/bin/krunner"

resulted in not starting the program at all.

I still found a work-around for the desktop portal, but it is not really 
nice. I added the 

Bug#1032368: bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

[Martin Steigerwald]

Mark and Simon: thank you.

Mark Hindley - 06.03.23, 17:22:12 CET:
> On Mon, Mar 06, 2023 at 03:25:18PM +, Simon McVittie wrote:
> > What I absolutely don't want is to make the change, and then 2 years
> > later get hate mail from someone telling me that I've broken their
> > system by making dbus-launch prevent /home from being unmounted and
> > "why can't you just" add an option to use daemon(3).
> 
> I think that is a very good point.
> 
> KDE is the only area where I have heard of this causing problems and I
> am not aware of any other reports that seem to have the same
> underlying cause. …

The upstream issue¹ refers to GNOME applications in RHEL 7 being 
affected. RHEL 7 would have a KDE without Systemd startup I bet².

[1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

[2] https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ 
(however I am not entirely sure whether that kind of startup is 
activated by default nowadays)

> I am not convinced there *is* a consensus for change and the risk of 
> changing the default for all users of legacy DBus activation seems 
> high.

Fair enough.

> Martin, I still think this is for KDE to address if it is important to
> them. I don't think I would push to change the behaviour of DBus in
> either Debian or Devuan at the moment.

I added that information and suggestion to the KDE bug report:

krunner starts applications with cwd "/" with init system other than 
systemd (openrc, runit, ...)
https://bugs.kde.org/show_bug.cgi?id=432975#c16

Let's see whether KDE developers are open to make the required changes.

Thanks,
-- 
Martin

Bug#1032368: bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

[Martin Steigerwald]

Dear Mark.

Thanks for looking at this!

Mark Hindley - 06.03.23, 12:52:08 CET:
> On Sun, Mar 05, 2023 at 09:59:35AM +0100, Martin Steigerwald wrote:
> > Package: dbus-x11
> > Version: 1.14.6-1devuan1
> > Severity: normal
> > X-Debbugs-Cc: mar...@lichtvoll.de
> > 
> > Dear Maintainer,
> > 
> > I also reported this to Debian as
> 
> Simon McVittie's is, of course, correct that src:dbus being forked in
> Devuan means this should be dealt with in Devuan. Notwithstanding
> that, I am very grateful for his thorough, considered and
> illuminating reply. The same behaviour is evident in a non-systemd
> Debian installation.

Yeah. Lorenzo confirmed this as well. He was able to replicate the issue 
on a Debian installation.

> Like Simon, I have no experience of KDE or krunner. I also agree that
> legacy DBus activation appears to be working here as intended and
> documented, with no guarantee on the cwd given.

Again: it is a kind of quick application starter. You press Alt-Space, 
enter something, it offers a variety of matches, you select one and press 
enter or just press enter to use the first match and that's it. If 
krunner's pwd is "/" then the application it started usually also has 
"/". Which means any file dialog started from it will have "/".

Additionally meanwhile I found that when I print a web site to PDF in 
Firefox the file dialog also starts with "/". This could be due to

export GTK_USE_PORTAL=1

in order to use KDE based file dialog with Firefox and other apps that 
use GTK.

None of this breaks the system. It just makes it more cumbersome to use.

I also wonder whether only Plasma desktop is affected.

> My gut reaction is that this issue is should really be resolved
> elsewhere. If it is crucial that krunner uses a particular working
> directory, then it needs to chdir() explicitly itself.

I understand. I  add this this suggestion to the KDE bug report. However 
as noted above: Besides KRunner some other processes appear to be 
affected. So it would be required to file an upstream report with any of 
those affected components. Might be the cleanest approach still. 
Especially as long as there are no guarantees.

I always thought that anything within a user session is using $HOME as 
pwd, but apparently that does not seem to be guaranteed or documented. 
And it may have been like that back in the days where almost everything 
related to a user desktop session was started from one place that 
started out from $HOME and all the child processes inherited pwd from 
that place.

It appears that for systems with other init systems there does not seem 
to be a consistent approach to handle this.

> I also quite understand his concern that changing the behaviour of
> DBus may have unintended consequences and I am certain that changing
> the behaviour of DBus during the freeze will not happen. I suppose
> early in the next cycle is possible. […]

Sure.

As I think that Simon is right and it is indeed is "/etc/X11/Xsession.d/
75dbus_dbus-launch" that started the session dbus. I mismatched the 
arguments and while I saw a third DBUS running under the user 
"messagebus" I did not make the connection that this is the one that is 
started by the runit service dir.

So my next approach would be to play around with "/etc/X11/Xsession.d/
75dbus_dbus-launch". First step would be to figure out whether "$HOME" is 
set to the session user home directory in that script. If yes, I'd try 
changing working directory to $HOME. If not… I am not sure, I may still 
go for changing pwd to the home directory of the main user of my system 
to actually verify whether this would be working as a work-around.

Will report back once I know more.

> Simon, might the implications of that be reviewed again upstream? I 
> found an upstream issue with patch to implement such behaviour that 
> has not been merged[1].

Interesting. That is from 4 years ago already.

> [1]  https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

Thanks,
-- 
Martin

Bug#1032368: dbus-x11: Several processes in Plasma session including krunner have / as current working directory

[Martin Steigerwald]

Hi Simon and Lorenzo.

First off: Kudos and appreciation that you took the time to respond this
thoroughly. Thank you!

Dear Lorenzo, I am also CC'ing you since some of the findings may point
at that it may make sense to resolve this within the runit-services package.
However I am certainly not sure yet about that. Especially as it would
require a solution for other init systems than Runit as well. Indeed there
are several options to fix the issue that Simon outlined. One of them would
involve upstream activity in KDE. And another one could probably work
from dbus-x11. So much choice to get a clue about!

Simon McVittie - 05.03.23, 12:58:48 CET:
> On Sun, 05 Mar 2023 at 09:33:08 +0100, Martin wrote:
> > This is with Devuan Ceres with Runit and Elogind. I am reporting
[…]
> This bug tracking system is for Debian, not Devuan. Is this
> reproducible on a Debian system with elogind, KDE and some
> non-systemd init system, perhaps by using a virtual machine?

I appreciate that. And I admit I did not yet test it in Debian. I consider
setting up a virtual machine to make sure.

> (In particular, I am not responsible for decisions made by the Devuan
> maintainers of dbus. The version number 1.14.6-1devuan1 indicates that

Fair enough! I could install the Debian Experimental version of the package,
but that still would not make this Devuan installation a Debian, so rather
going for the virtual machine approach.

> In my experience, sysv-rc and openrc (sysvinit as process 1) are
> generally better-integrated in Debian than runit. Is this
> reproducible with sysv-rc or openrc?

Lorenzo confirmed this for SysVInit as well:

https://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2023-February/005929.html

I asked for confirmation whether this confirmation is from a Devuan or a
Debian based system.

Also the KDE bug report I mentioned that this happens across distributions
and across different init systems¹. It originally has been reported for Gentoo.

[1] https://bugs.kde.org/432975

> How is your `dbus-daemon --session` process started? Is it started by
> /etc/X11/Xsession.d/75dbus_dbus-launch, or by X11 autolaunching?
> What is its current working directory?

I bet you mean the dbus service which

DBUS_SESSION_BUS_ADDRESS='unix:path=/tmp/dbus-uwFj[…],guid=9aaf[…]'

refers to. According to lsof this is running as PID 9107 currently.

Its parent process is runit. Its working directory is "/".

It seems to be run with:

% cat run
#!/usr/bin/env /lib/runit/invoke-run
#Copyright: 2022-2023 Lorenzo Puliti <[…]>
#License: CC0-1.0

exec 2>&1

if [ ! -d /var/run/dbus ]; then
install -d /var/run/dbus -o messagebus -g messagebus
fi
mountpoint -q /proc/ || exit 162
if [ -x /usr/bin/dbus-uuidgen ]; then
/usr/bin/dbus-uuidgen --ensure
fi

if [ -e /etc/runit/verbose ]; then
echo "invoke-run: starting ${PWD##*/}"
fi
exec dbus-daemon --system --nofork --nopidfile

Well I bet basically that would explain its current working directory being
"/". However it would not explain it for a SysVInit based system.

Also above runit service comes from the runit-services package and the
issue has been already there before Lorenzo brought this package
into Debian and before I had it installed.

Grepping for processes with dbus in their name or arguments also reveals
one dbus service that appears to have been launched by sddm which
is the display manager I use:

% ps aux | grep "[d]bus"
root  1991  0.0  0.0   2344  1268 ?Ss   Mär04   0:00 runsv dbus
root  1992  0.0  0.0   2344  1368 ?Ss   Mär04   0:00 runsv 
dbus.dep-fixer
_runit-+  2015  0.0  0.0   2492  1452 ?SMär04   0:00 svlogd -tt -b 
2048 /var/log/runit/dbus
message+  2016  0.0  0.0   6536  4896 ?SMär04   0:04 dbus-daemon 
--system --nofork --nopidfile
sddm  6587  0.0  0.0   6652  2316 ?SMär04   0:00 dbus-launch 
--autolaunch 3d6f92a09aa53b38614887db63ce99a6 --binary-syntax --close-stderr
sddm  6614  0.0  0.0   4404  2128 ?Ss   Mär04   0:00 
/usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 
--session
martin9106  0.0  0.0   6740  2424 ?SMär04   0:00 
/usr/bin/dbus-launch --exit-with-session --sh-syntax
martin9107  0.0  0.0   7096  4696 ?Ss   Mär04   0:12 
/usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
martin9317  0.0  0.0 234536 25088 ?Sl   Mär04   0:03 
/usr/bin/gmenudbusmenuproxy

The working directory of PID 6614 is also /. I bet it is not related to the
bug I reported. It seems to be a special dbus service just for the display
manager and "/" as working directory may just be about right for that
one.

> /etc/X11/Xsession.d/75dbus_dbus-launch is the way dbus-daemon is meant
> to be started on most Debian-derived systems that are not using
> `systemd --user`. It starts the `dbus-daemon --session` as part of X
> session startup, inheriting its current working directory and various
> other 

Bug#1032368: Bug report for Devuan

[Martin Steigerwald]

dbus-x11: Several processes in Plasma session including krunner have / 
as current working directory
https://bugs.devuan.org/745

-- 
Martin

Bug#663436: modprobe: does not seem to set module options for snd_hda_intel

[Martin Steigerwald]

Hi Marco.

Marco d'Itri - 28.01.23, 23:04:43 CET:
> Do you have any feedback?
> Can you still reproduce this on a modern system?

No idea.

I do not even use the hardware involved in that bug report anymore. Feel 
free to close it.

Best,
-- 
Martin

Bug#1025051: O: fsmark -- benchmark for simulating synchronous write workloads

[Martin Steigerwald]

Package: wnpp
Severity: normal
X-Debbugs-Cc: martin.steigerw...@proact.de
Control: affects -1 src:fsmark

I intend to orphan the fsmark package.

The package description is:
 The fs_mark benchmark tests synchronous write workloads. It can vary
 the number of files, directory depth, etc. It has detailed timings
 for reads, writes, unlinks and fsyncs that make it good for simulating
 mail servers and other setups.


Reasons:

I do not use fs_mark anymore.

Upstream asked me to convert the package to a native package. I'd like
to keep the gbp repository layout.

I am not aware of major development on fsmark.


Hints for someone who wants to take over maintenance:

Due to the lack of development and the simplicity of the package except
updating to current Debian standards there may not be all that much to do.

Last release of package is from 6th of February 2019 and so far it just
kept compiling. There was one binary rebuild.

Apparently I did some further commits to the package repository at

https://salsa.debian.org/debian/fsmark/

that I never released.

Also there is one merge request about removing unnecessary constraints
open on Salsa.

When you take over the package, it is of course up to you whether to keep
current gbp / quilt layout of the repo or convert to a native package. 

Last upstream repository I am aware of is from 2014:

git://oss.sgi.com/dgc/fs_mark
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=dgc/fs_mark;a=summary

These are gone. There might be an archive of those at archive.org

Upstream developers I last had contact to are Dave Chinner and Ric Wheeler.
This was also in 2014. In case you like to know their last e-mail addresses
contact me by private mail.

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#1025050: O: fsmark -- benchmark for simulating synchronous write workloads

[Martin Steigerwald]

Package: wnpp
Severity: normal
X-Debbugs-Cc: martin.steigerw...@proact.de
Control: affects -1 src:fsmark

I intend to orphan the fsmark package.

The package description is:
 The fs_mark benchmark tests synchronous write workloads. It can vary
 the number of files, directory depth, etc. It has detailed timings
 for reads, writes, unlinks and fsyncs that make it good for simulating
 mail servers and other setups.


Reasons:

I do not use fs_mark anymore.

Upstream asked me to convert the package to a native package. I'd like
to keep the gbp repository layout.

I am not aware of major development on fsmark.


Hints for someone who wants to take over maintenance:

Due to the lack of development and the simplicity of the package except
updating to current Debian standards there may not be all that much to do.

Last release of package is from 6th of February 2019 and so far it just
kept compiling. There was one binary rebuild.

Apparently I did some further commits to the package repository at

https://salsa.debian.org/debian/fsmark/

that I never released. See tracker page for the package:

https://tracker.debian.org/pkg/fsmark

Also there is one merge request about removing unnecessary constraints
open on Salsa.

When you take over the package, it is of course up to you whether to keep
current gbp / quilt layout of the repo or convert to a native package. 

Last upstream repository I am aware of is from 2014:

git://oss.sgi.com/dgc/fs_mark
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=dgc/fs_mark;a=summary

These are gone. There might be an archive of those at archive.org

Upstream developers I last had contact to are Dave Chinner and Ric Wheeler.
This was also in 2014. In case you like to know their last e-mail addresses
contact me by private mail.

Bug#1024969: runit-services: several Dbus services fail to start at boot when this package is installed

[Martin Steigerwald]

Lorenzo - 28.11.22, 01:46:04 CET:
> Hi Martin,
> 
> [ was Re: Runit-services RFS ]
> 
> > Martin Steigerwald  wrote:
> > > 1) Major issue: Once I install runit-services Network Manager is
> > > not started on boot automatically anymore. I tried it on two
> > > laptops. On one I removed runit-services again. Then Network
> > > Manager started again on next reboot. As I use Devuan
> > > network-manager package still has the init script
> > > /etc/init.d/network-manager. In /var/log/boot I have only:
[…]
> > > Another thing I just discovered. The bluetooth related services
> > > are not started when your package runit-services is installed.
> >
> > To summarize: for a runit-init user:
> >  * with this package installed, each service that connects to
> > (depends on) dbus for which there is a sysv service but not a
> > runscript will fail to start at boot, because it's started as sysv
> > script when dbus is still not available. Such services can be
> > started manually later.
> > 
> >  * without this package the sysv-emulation
> > 
> > (/lib/runit/run_sysv_scripts) run sysv scripts at boot in the
> > correct (Sysv) order, so everything works as expected

Do I get this right, that first runit sysv emulation runs the init 
scripts in the correct order and it starts native runit services? Could 
runit be instructed to start at least certain or even all Runit services 
before running the init scripts?

> > So installing this package will make dbus-services that are not
> > included in runit-services, like netwok-manager, bluetoothd and
> > others, fail to start at boot.

> run_sysv_scripts run sysvscripts at boot in the right order, but it
> skips the sysv script when a native runscript with the same name
> exists. This was designed to allow a gradual transition from
> sysvscripts to runscripts; of course it doesn't work with dbus
> because it's at the start of a dependency chain.
> 
> The very quick solution to this is to temporary remove dbus and maybe
> elogind from this package.
> 
> Another solution is to merge dbus services into this package like
> there's no tomorrow.

This has the disadvantage that whenever there is a new DBUS service 
introduced by some package it will fail again until your package "runit-
services" picks it up.

> So Network Manager, Avahi, bluez, wdm, lxdm, gdm3 (not sure gmd3 works
> with elogind). Any other relevant service that I'm not considering?

I remember Devuan installation reports that GNOME works with elogind. 
Not sure whether this was with gdm3 or another display manager.

Best,
-- 
Martin

Bug#1009880: fio: New upstream version available (3.30)

[Martin Steigerwald]

Hi Salvatore.

Am Dienstag, dem 19.04.2022 um 21:25 +0200 schrieb Salvatore Bonaccorso:

[…]
> There is a new upstream version available for fio, 3.30 at time of
> writing. If you have time, can you upload the new version to unstable?

Thanks for letting me know.

I prepared fio-3.30 and uploaded the results to the Salsa repo.

I asked my sponsor Sven to upload it. He may be busy so it may take a
while.

Best,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#997201: fio: FTBFS: crc/../os/os-linux.h:17:10: fatal error: linux/raw.h: No such file or directory

[Martin Steigerwald]

Hello Lucas, hello everyone.

Am Samstag, dem 23.10.2021 um 21:11 +0200 schrieb Lucas Nussbaum:
> Source: fio
> Version: 3.25-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
[…]
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

I currently do not have much time at hand to attend to this.

Feel free to NMU.

Thanks,

Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
www.proact.de
Südwestpark 43 •
90449 Nürnberg •
Germany
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfData  |
#ThePowerOfTogether

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Please read more in Proacts’ 
privacy notice,

Bug#964139: Work-around for missing Network Manager init script in network-manager package

[Martin Steigerwald]

Hi!

As Michael is unwilling to restore the init script for Network Manager, 
to anyone who is affected by this bug:

You can install package orphan-sysvinit-scripts by Matthew Vernon. It 
contains init scripts for Network Manager and some other services that 
in Debian come without init scripts.

By installing it and testing whether it works you help with ensuring 
that Debian can be used with something else than Systemd as PID 1.

In case you find any bug, please do not report it here. Use the package 
orphan-sysvinit-scripts to report any bugs.

Best,
-- 
Martin

Bug#981555: does not appear to respond to DBUS interface anymore

[Martin Steigerwald]

Dear Simon.

I post part of your reply to me personally, cause I accidentally replied
to you personally, publicly in order to give further information to the
bug report. I hope you don't mind. I think there is nothing private in
there.

Am Montag, dem 01.02.2021 um 14:19 + schrieb Simon McVittie:
> > Hmmm, shall I try downgrading to glib 2.66.4-1 from snapshots?
>
> If that resolves this, that would be a useful data point. No need to
> use snapshots, 2.66.4-1 is still current in bullseye at the moment.
>
> A more informative data point would be to try the test-builds
> described
> in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981420#28> which
> partially revert only the most relevant change. I would guess that
> with
> the set of packages versioned 2.66.4-3+revert981420targeted, it would
> work again, perhaps with this warning message logged (in your case
> it might be in ~/.xsession-errors, or /dev/null, or wherever else a
> Plasma session on a non-systemd system puts session services' output):
>
>     GLib-GIO: Not suppressing use of DBUS_SESSION_BUS_ADDRESS because
> not setuid, even though AT_SECURE

After installing

- libglib2.0-0_2.66.4-3+revert981420targeted_amd64.deb
- libglib2.0-bin_2.66.4-3+revert981420targeted_amd64.deb

and restarting GNOME keyring daemon the issue is gone.

There is no such error message in ~/.xsession-errors, where Plasma
indeed logs session services output:

% grep "Not suppressing" ~/.xsession-errors

yields no result

Thank you very much again for your detailed answer. If I can do
something else to help you find a solution to this bug, please let me
know.

As for using KWalletManager as you suggested: Well I use it, yet
Evolution – specifically evolution-data-server package - depends on
GNOME keyring.

Best,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfTogether

Bug#981555: does not appear to respond to DBUS interface anymore

[Martin Steigerwald]

Resending: I accidentally sent this to Simon directly. Simon nonetheless
kindly replied to me already. I hope I am able to get back to it
tomorrow.


Dear Simon,

Thank you for your detailed reply.

Am Montag, dem 01.02.2021 um 12:47 + schrieb Simon McVittie:
> On Mon, 01 Feb 2021 at 12:06:04 +0100, Martin Steigerwald wrote:
[… Evolution not asking for keyring password anymore …]
> > Since this worked before I do not consider this to be an upstream
> > issue.
> > However also 'gnome-keyring' package does not appear to have been
> > changed
> > recently. So it may be related to the upgrade of a different
> > package.
>
> I think this might be triggered by security hardening in GLib that
> results
> in gnome-keyring-daemon no longer trusting its parent process to
> supply it
> with a DBUS_SESSION_BUS_ADDRESS. See <https://bugs.debian.org/981420>
> and
> upstream issue <https://gitlab.gnome.org/GNOME/glib/-/issues/2305>.

I see.

> > I am using Runit as PID 1.
>
> Presumably that means you're getting your D-Bus session bus from dbus-
> x11 (dbus-launch), because the recommended implementation
> dbus-user-session requires systemd?

I have dbus-x11 installed, but dbus-user-session is not installed.

> The various consequences of a non-systemd init, not all of which are
> immediately obvious, are not really something that GNOME projects are
> designed to support.

In addition to other reasons that is one reason I use KDE's Plasma. They
kept Systemd support stuff optional so far.

> The reporter of #981420 *is* using systemd, but one theory about why
> their gnome-keyring isn't working is that they might be using dbus-x11
> rather than dbus-user-session. I haven't been able to confirm or
> disprove that theory yet.

Hmmm, shall I try downgrading to glib 2.66.4-1 from snapshots?

> We try to keep this working in Debian, but there's
> a limit to what we can do in that direction: if the underlying 
> system does not meet various design assumptions then sometimes we will
> just have to say "sorry, you don't have the requirements for this".

Well of course I'd like this to continue to work and if it might be
triggered by security hardening in Glib as you pointed out above, it may
not be related to Systemd at all? A "design assumption" and hard
"requirements" are two different things for me. I prefer software that
works without relying on assumptions.

Thanks,


Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfTogether

Bug#981555: does not appear to respond to DBUS interface anymore

[Martin Steigerwald]

Am Montag, dem 01.02.2021 um 12:06 +0100 schrieb Martin Steigerwald:
> Kernel: Linux 5.11.0-rc6-tp520 (SMP w/4 CPU threads; PREEMPT)

Just to make sure I retested this with linux-image-5.10.0-2-amd64
5.10.9-1 and got back the same result as reported.

Best,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Linda Höljö
#ThePowerOfTogether

Bug#981555: does not appear to respond to DBUS interface anymore

[Martin Steigerwald]

Package: gnome-keyring
Version: 3.36.0-1
Severity: important

Dear maintainers,

Since this work week Evolution on my laptop does not ask for GNOME keyring
password anymore. Instead after some kind of a timeout it directly asks
for the password of the connection.

It does so for retrieving mails, for sending mails, for calendar and 
addressbook access. I am using Evolution EWS with Office 365.

Since this worked before I do not consider this to be an upstream issue.
However also 'gnome-keyring' package does not appear to have been changed
recently. So it may be related to the upgrade of a different package.

I do see

kdeinit5: Got EXEC_NEW 'dbus-send' from launcher.
kdeinit5: preparing to launch 'libkdeinit5_dbus-send'
Could not open dbus-send using a library: Cannot load library 
libkdeinit5_dbus-send: (libkdeinit5_dbus-send: Kann die Shared-Object-Datei 
nicht öffnen: Datei oder Verzeichnis nicht gefunden)
kdeinit5: PID 13520 terminated.

in ~/.xsession-errors which may be related.

However I did not find 'libkdeinit5_dbus-send' anywhere with 'apt-file search'.

GNOME Keyring daemon, which to my understanding provides Secrets Services
DBUS API, is running, excerpt from 'ps aux':

someuser   13491  0.0  0.0  15756  4984 ?SL   08:52   0:00 
/usr/bin/gnome-keyring-daemon --daemonize --login

However also 'qdbus' reports that the DBUS API is not accessible:

% qdbus org.freedesktop.secrets 
Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.

It does not even seem to exist:

% qdbus | grep secrets
[… nothing …]

However also if started manually GNOME Keyring does not report an error:

% /usr/bin/gnome-keyring-daemon --login
[… keeps running, no output, even after Evolution failing to connect DBUS
API …]

I am using Runit as PID 1. This has not been an issue before.

Thanks,
Martin

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

Kernel: Linux 5.11.0-rc6-tp520 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages gnome-keyring depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.20-1
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gcr  3.38.1-1
ii  libc62.31-9
ii  libcap-ng0   0.7.9-2.2+b1
ii  libcap2-bin  1:2.44-1
ii  libgck-1-0   3.38.1-1
ii  libgcr-base-3-1  3.38.1-1
ii  libgcrypt20  1.8.7-2
ii  libglib2.0-0 2.66.4-3
ii  p11-kit  0.23.22-1
ii  pinentry-gnome3  1.1.0-4

Versions of packages gnome-keyring recommends:
ii  gnome-keyring-pkcs11  3.36.0-1
ii  libpam-gnome-keyring  3.36.0-1

gnome-keyring suggests no packages.

-- debconf-show failed

Bug#577597: Still happens with util-linux 2.32-0.1 and Linux 4.17-rc7

[Martin Steigerwald]

Chris Hofstaedtler - 27.12.20, 23:58:01 CET:
> Control: tags -1 + moreinfo
[…]
> * Martin Steigerwald  [180531 22:38]:
> > found 577597 2.32-0.1
> > thanks
> > 
> > This issue still happens with util-linux 2.32-0.1 and on self
> > compiled Linux 4.17-rc7 with Debian Sid.
> 
> Please let me know if this is still a problem on a default install
> of bullseye:
> 
> - with the Debian-built 5.9.x kernel
> - with systemd
> - as installed by the Debian Installer

I do not have such a default install.

> If this happens only on non-default installs, please let me know the
> differences from a default install.
> 
> Also, please provide the kernel boot log - especially the rtc/clock
> bits -, and output of
[…]

Honestly written, I am not really interested to even check at the 
moment. I do not have a default install meanwhile anyway (runit + 
elogind instead of systemd).

Maybe the original reporter likes to test or maybe some of the other 
ones who posted.

From my side I do not even care about this bug anymore, as I use FAT 32 
quite rarely these days. And when I do I do not care about the two hour 
difference. I am okay with closing the bug. But I don't know about the 
original reporter or the other ones who commented.

Ciao,
-- 
Martin

Bug#974860: Forwarded to upstream

[Martin Steigerwald]

Silvério Santos - 24.12.20, 14:18:18 CET:
> forwarded -1 https://bugs.kde.org/show_bug.cgi?id=430787

Please retest once you upgraded to Plasma 5.20 and KF 5.77. They should 
appear in testing soon.

Have a Merry Christmas if you celebrate it, have a quiet and peaceful 
time,
-- 
Martin

Bug#973973: plasma-workspace: screen looking does not work: kscreenlocker: Greeter Process not available

[Martin Steigerwald]

Martin Steigerwald - 08.11.20, 14:24:11 CET:
> On pressing Ctrl-Alt-L or using one of the 'qdbus' commands I see the
> following messages in ~/.xsession-errors:
> 
> kscreenlocker: Greeter Process not available
[…]

After another apt dist-upgrade today and after rebooting screenlocking 
works as usual.

Yet the relevant packages have been installed before, they were updated 
yesterday, maybe the issue happened due to the upgrade? I think I did 
not restart after this update as it appeared minor to me. If this is to 
be expected while upgrading while in the session, please close the bug. 
I will look how it works now.

Start-Date: 2020-11-07  09:49:21
Commandline: apt dist-upgrade
Requested-By: martin (1000)
Install: […] libkscreenlocker5:amd64 (5.19.5-2, 5.19.5-3), […] kde-
config-screenlocker:amd64 (5.19.5-2, 5.19.5-3), […]
End-Date: 2020-11-07  09:57:55

Ciao,
-- 
Martin

Bug#973973: plasma-workspace: screen looking does not work: kscreenlocker: Greeter Process not available

[Martin Steigerwald]

Package: plasma-workspace
Version: 4:5.19.5-3
Severity: important

Dear Maintainer,

apparently it does not happen to everyone who updated to Plasma 5.19.5, but
it definitely happened here:

- The screen is not locked after standby or hibernating to disk although
  the option in Systemsettings is set
- I cannot lock the screen manually by pressing Ctrl-Alt-L.
- I cannot lock the screen with a DBUS command, I tried:
  - qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
  - qdbus org.kde.ksmserver /ScreenSaver org.freedesktop.ScreenSaver.Lock

On pressing Ctrl-Alt-L or using one of the 'qdbus' commands I see the
following messages in ~/.xsession-errors:

kscreenlocker: Greeter Process not available
ktp-kded-module: "screen-saver-away" state change: 
TelepathyKDEDModulePlugin::Enabled
ktp-kded-module: plugin queue activation: "unset" ""

I think the issue is that the greeter process is not available. If Martin
Graesslin's blog post is still up to date there should be a
'kscreenlocker_greet' process. I do not have this process.

[1] 
https://blog.martin-graesslin.com/blog/2014/05/screenlocker-architecture-in-plasma-next/

Thanks,
Martin


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

Kernel: Linux 5.9.6-tp520 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages plasma-workspace depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.20-1
ii  drkonqi  5.19.5-3
ii  frameworkintegration 5.74.0-2
ii  gdb  9.2-1
ii  iso-codes4.5.0-1
ii  kactivitymanagerd5.19.5-3
ii  kded55.74.0-2
ii  kinit5.74.0-2
ii  kio  5.74.0-2
ii  kpackagetool55.74.0-2
ii  kwin-common  4:5.19.5-3
ii  libappstreamqt2  0.12.11-1
ii  libc62.31-4
ii  libcolorcorrect5 4:5.19.5-3
ii  libgcc-s110.2.0-16
ii  libgps26 3.20-12+b1
ii  libice6  2:1.0.10-1
ii  libkf5activities55.74.0-2
ii  libkf5activitiesstats1   5.74.0-2
ii  libkf5authcore5  5.74.0-2
ii  libkf5baloo5 5.74.0-2
ii  libkf5bookmarks5 5.74.0-2
ii  libkf5calendarevents55.74.0-2
ii  libkf5completion55.74.0-2
ii  libkf5config-bin 5.74.0-2
ii  libkf5configcore55.74.0-2
ii  libkf5configgui5 5.74.0-2
ii  libkf5configwidgets5 5.74.0-2
ii  libkf5coreaddons55.74.0-2
ii  libkf5crash5 5.74.0-2
ii  libkf5dbusaddons55.74.0-2
ii  libkf5declarative5   5.74.0-2
ii  libkf5globalaccel-bin5.74.0-2
ii  libkf5globalaccel5   5.74.0-2
ii  libkf5guiaddons5 5.74.0-3
ii  libkf5holidays5  1:5.74.0-2
ii  libkf5i18n5  5.74.0-3
ii  libkf5iconthemes55.74.0-2
ii  libkf5idletime5  5.74.0-2
ii  libkf5itemmodels55.74.0-2
ii  libkf5jobwidgets55.74.0-2
ii  libkf5kdelibs4support5   5.74.0-3
ii  libkf5kiocore5   5.74.0-2
ii  libkf5kiofilewidgets55.74.0-2
ii  libkf5kiogui55.74.0-2
ii  libkf5kiowidgets55.74.0-2
ii  libkf5networkmanagerqt6  5.74.0-2
ii  libkf5newstuff5  5.74.0-2
ii  libkf5notifications5 5.74.0-2
ii  libkf5notifyconfig5  5.74.0-2
ii  libkf5package5   5.74.0-2
ii  libkf5people55.74.0-2
ii  libkf5peoplewidgets5 5.74.0-2
ii  libkf5plasma55.74.0-2
ii  libkf5plasmaquick5   5.74.0-2
ii  libkf5prison55.74.0-2
ii  libkf5quickaddons5   5.74.0-2
ii  libkf5runner55.74.0-2
ii  libkf5service-bin5.74.0-2
ii  libkf5service5   5.74.0-2
ii  libkf5solid5 5.74.0-2
ii  

Bug#969171: akonadi-server expects akonadi-backend-mysql allthough any sql backend should work

[Martin Steigerwald]

severity 969171 normal
thanks

Dear Eric.

Akonadi will use whatever database is set in the configuration file, by 
default on first startup MySQL if the MySQL backend has been installed at 
first startup. So if you use it with an existing home directory that has 
MySQL specified as database backend it needs the MySQL database backend 
of Akonadi to operate with the existing configuration. See the file: 
'~/.config/akonadi/akonadiserverrc'. This can happen as easily as 
starting once with the MySQL backend installed, as Plasma starts Akonadi 
automatically in its default configuration. Then you have an empty 
MariaDB based Akonadi. If you then switch to PostgreSQL this error 
occurs.

Please ask on debian-kde and/or upstream kdepim-users mailing list for 
support. The Debian bug tracker is not for user support questions. Also 
review previous threads on this topic there. Note that on switching the 
database Akonadi will start anew and some information only stored in the 
database will be lost.

I think it is not a bug of the package. But it is definitely not severity 
grave as Akonadi is perfectly usable here in exact the same version 
(usable to the extent Akonadi works reliable, but that is an upstream 
issue). So downgrading severity to normal.

I have seen repeatedly seen that you set too high bug severity. If the 
package does not work for me does not mean that its automatically grave 
severity. Especially when it is, as I assume, a configuration error. So 
please refrain from setting grave when it isn't. It just causes 
additional work for the already overloaded Debian Qt/KDE team. If you 
are unsure please ask first in debian-kde mailing list. That is part of 
what it is there for.

Best,
-- 
Martin

Bug#964139: [Pkg-utopia-maintainers] Bug#964139: Bug#964139: Bug#964139: NMU (delayed/14) to fix two init compatibility issues

[Martin Steigerwald]

Michael Biebl - 15.09.20, 21:37:18 CEST:
> The removal of the SysV init script was not a mistake that needs to be
> corrected.

Why did you remove it?

The changelog does not mention a reason as I pointed out already.

Thanks,
-- 
Martin

Bug#936146: archivemail - Python 3 porting

[Martin Steigerwald]

Hi!

I used this frequently enough to be hesitant to let apt dist-upgrade 
remove it on my system currently.

But I understand it may not make sense to port it as its hard and 
upstream is not active anymore.

Is there an alternative in Debian repository?

Best,
-- 
Martin

Bug#964139: network-manager: Please restore removed init script.

[Martin Steigerwald]

Dear Michael!

Again I ask you to reconsider and put the init script back in. If that 
would be too much work for you, I am sure someone would be willing to 
provide a patch.

I like to remind you about the winning choice of last years GR¹. It is 
specifically labeled as:

Option 2 "B: Systemd but we support exploring alternatives"

Please note the "but we support exploring alternatives".

Also look at the following excerpt of the choice:

"""
The Debian project recognizes that systemd service units are the
preferred configuration for describing how to start a daemon/service.
However, Debian remains an environment where developers and users can
explore and develop alternate init systems and alternatives to systemd
features. Those interested in exploring such alternatives need to
provide the necessary development and packaging resources to do that
work. Technologies such as elogind that facilitate exploring
alternatives while running software that depends on some systemd
interfaces remain important to Debian. It is important that the project
support the efforts of developers working on such technologies where
there is overlap between these technologies and the rest of the project,
for example by reviewing patches and participating in discussions in a
timely manner.
"""

Not only in my point of view the GR last year¹ does not mean that 
"systemd has won!". Especially the GR does not endorse "drop all init 
scripts".

Additionally you provided no reason whatsoever for the removal of the 
init script in the changelog:

"""
network-manager (1.25.91-1) unstable; urgency=medium

  * New upstream version 1.25.91 (1.26 rc2)
  * Remove SysV init script

 -- Michael Biebl <[…]>  Thu, 02 Jul 2020 01:17:08 +0200
"""

And you did not answer to this bug report since almost a month except 
for setting its severity to "wishlist".

Removing the init script breaks existing systems using something else 
than systemd together with Network Manager. This is a use case that 
worked for a long, long time. It still does work once the init script is 
copied back after removal. There is no warning in debconf, no 
explanation in README.Debian or NEWS.Debian. All current Debian Buster 
users with something else than systemd as PID 1 and with Network Manager 
would be left in the dark about why the upgrade broke their networking 
setup.

On the other hand I do not see any benefit from removing the init script. 
All it caused up to now is further friction.

If you have doubts about maintaining and bug fixing the init script, in 
case there are bugs, I am sure someone would be willing to do that. 
Current support for sysvinit, runit, elogind and other alternatives to 
Systemd and (some of) it's parts is pretty good in Debian, to a great 
extent thanks to the wonderful cooperation with the Devuan project.

So please reconsider.

[1] https://www.debian.org/vote/2019/vote_002

Thank you,
-- 
Martin

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

Bug#964139: network-manager: Please restore removed init script.

[Martin Steigerwald]

Martin Steigerwald - 02.07.20, 18:47:52 CEST:
> Michael, I fully second Mark's request to restore the init script.
[…]
> /me now copies the init script to a safe location in order to be able
> to restore it in case it gets removed on upgrade.

I can confirm that the init script *was* already removed on my system and 
that Network Manager then was not started after reboot.

Before I rebooted I downloaded the previous version from 
snapshot.debian.org which for some reason appeared only to have been 
available as an IA64 package, which of course does not matter for the 
init script.

I restored the init script from the previous package version to its 
original location. In my opinion this deserves a much higher severity 
for this bug report, but I will not start a "I override the bug 
severity" you set game here.

I do not think the the GR from last year justifies such an behavior.

Best,
-- 
Martin

Bug#964139: network-manager: Please restore removed init script.

[Martin Steigerwald]

Dear Mark, dear Michael.

Michael, I fully second Mark's request to restore the init script.

It works. Why do I know? Cause on this machine I run a Plasma desktop 
with Network Manager with runit as initialization system. Network 
Manager works here *just fine*. Plasma just works fine, using elogind.

Removing the init script basically breaks Network Manager on this last 
Debian system I still use, also for maintaining the two packages I 
maintain for Debian.

I see *no need whatsoever* to actively break running systems this way. 
(And force Devuan to fork another package.)

/me now copies the init script to a safe location in order to be able to 
restore it in case it gets removed on upgrade.

Best,
-- 
Martin

Bug#963974: faillog command does not display anything since a long time

[Martin Steigerwald]

Am Montag, den 29.06.2020, 16:32 +0200 schrieb Martin Steigerwald:
> Package: libpam-modules
> Version: 1.3.1-5
> Severity: normal
[…]
> I digged on the internet I found Red Hat apparently removed it during
> RHEL 5 development already. I digged in libpam-modules Debian
> changelog and NEWS file and found nothing about 'faillog' or
> pam_tally.
>
[…]
> Not sure what the best resolution for Debian would be. Maybe just a
> note in NEWS.Debian or… something else?

I tested various distributions: Both CentOS 8.2 and SLES 15 SP 1 have no
faillog command. The Debian 10, Debian Sid and the Debian based ones
Devuan 3 aka Beowolf and Ubuntu 20.04 LTS still have it.

Removing it would break setups with manually enabled pam_tally though.

Best,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Jonas Persson
•
Oliver Kügow
– Delivering Business Agility –

Bug#963974: faillog command does not display anything since a long time

[Martin Steigerwald]

Package: libpam-modules
Version: 1.3.1-5
Severity: normal

Dear maintainers,

quite some time, quite some Debian releases ago, I found during a Linux
training I held that faillog would not display anything anymore, while
lastlog still does.

Finally I took time to research this a bit. I learned quickly that
pam_tally is required for it to work. However it is not enabled by
default in Debian, `grep tally /etc/pam.d/*' does not return any results.

I digged on the internet I found Red Hat apparently removed it during
RHEL 5 development already. I digged in libpam-modules Debian changelog
and NEWS file and found nothing about 'faillog' or pam_tally.

However in the manpage 'pam_tally(8)' I found:

   pam_tally has several limitations, which are solved with
   pam_tally2. For this reason pam_tally is deprecated and will be
   removed in a future release.

'pam_tally2' is included in Debian, yet also not enabled. And its file
format is not compatible with 'faillog', as manpage 'pam_tally2(8)' states:

   pam_tally2 is not compatible with the old pam_tally faillog
   file format. This is caused by requirement of compatibility of
   the tallylog file format between 32bit and 64bit architectures
   on multiarch systems.

So by default the Debian system contains a command that does not work out
of the box. And experienced user can dig up how to enable pam_tally, yet
this situation is still somehow inconsistent.

pam_tally2 has a command 'pam_tally2', but pam_tally2 by default is also
not enabled.

However there is 'lastb' command which displays the last failed login
attempt for each user. I am going to use that for the training for now
and mention that faillog is dysfunctional unless pam_tally is enabled,
which is deprecated.

Not sure what the best resolution for Debian would be. Maybe just a note
in NEWS.Debian or… something else?

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

Kernel: Linux 5.8.0-rc2-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libaudit1  1:2.8.5-3+b1
ii  libc6  2.30-8
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libpam-modules-bin 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux13.0-1+b3

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- debconf-show failed

Bug#646692: pam_umask: umask in /etc/login.defs not respected cause libpam_umask is not configured

[Martin Steigerwald]

Dear Steve, dear Andreas, dear Debian contributors,

Revisiting this topic for my trainings I see that this is not yet fixed.

*However* there is a merge request available in Salsa:

enable usergroups and add pam_umask in common-session(-noninteractive)

https://salsa.debian.org/vorlon/pam/-/merge_requests/3

Any chance you could merge it in time for Bullseye?

For now I will document that one still has to enable pam_umask manually.
Also pam-auth-update does not offer to enable it so I manually added

session optional   pam_umask.so

after end of 'pam-auth-update' maintained block in /etc/pam.d/common-
session.

After this PAM sets the umask according to the UMASK setting in
'/etc/login.defs'.

(Sorry for long signature and probably added HTML part, I can't
influence this for my work mail account.)

Best,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
René Schülein
 •
Jonas Hasselberg
 •
Jonas Persson
•
Oliver Kügow
– Delivering Business Agility –

Bug#961913: kmail: the access and reading of the received messages is often very slow

[Martin Steigerwald]

forwarded 961913 https://bugs.kde.org/422336
thanks

Forwarded to:

Bug 422336 - kmail: the access and reading of the received messages is 
often very slow

https://bugs.kde.org/422336

Also relates to:

Bug 367892 - During folder synchronisation Akonadi blocks out other 
operations like deleting or viewing mails

https://bugs.kde.org/367892

Thanks,
-- 
Martin

Bug#961913: kmail: the access and reading of the received messages is often very slow

[Martin Steigerwald]

tags 961913 upstream
thanks

Dear Merlin.

merlin - 31.05.20, 14:01:27 CEST:
> Package: kmail
> Version: 4:20.04.1-1
> Severity: important
[…]
>  the access and reading of the received messages is often very slow a
> message appears
> "Reception of the content of the folder  please wait" Same problem for
> the trashing of messages.
> The CPU increase to 100%
> an akonadictl fsck or akonadictl vacuum does not improved .
> Its new

Thank you very much.

I recommend to create an upstream bug report at https://bugs.kde.org as 
well. It is an upstream bug which has nothing to do with the Debian 
packaging. Once you created it, please share a link to it to the Debian 
bug report.

However… first, please make sure you have some more information at hand 
that can help to debug the issue. Currently the only thing developers 
can do about your bug report is to ask for further information. Well or 
do nothing about it.

If it is your goal to see your issue fixed, then it is helpful to help 
the developer to help you by providing any information that may be 
helpful.

At the very least I'd include the following in the upstream bug report:

- Of course exact versions of the involved components.

- Your setup. So you use POP3 with local maildir or anything else? Which 
resources do you have configured and so on. Anything special settings you 
use?

- Start Akonadi from a shell window and report any log messages that may 
be related to the issue. Or state that you checked the log and there are 
none if that is the case. Of course redact as needed for privacy.

- Steps to reproduce the problem as best to your current knowledge.

- Detailed information on what happens on your system when you do those 
steps. 100% CPU usage is not very detailed. It would help already to 
know which processes are using the CPU. "pidstat", contained in package 
"sysstat", or atop can provide good insight on what is going on. You may 
even share an atop recording with 10 second interval if you feel 
comfortable with others knowing what processes ran on your system at 
that time. Otherwise I bet some lines of "pidstat" output will also do. 
Also when did the "Reception of the content of the folder, please wait" 
message appear? On clicking another folder while mail retrieval / 
filtering was still working in the background? Things like that.

- Is it a regression and if so since when? You wrote "It's new", but not 
since which version. For Debian the developer can guess it was 19.08, 
cause that was the previous version in Debian, however the upstream 
developers may not know about that. Also you could have upgraded from 
Debian Stable to Unstable and then the previous version would have been 
a much older one.

- Also I suggest to use the Akonadi component, if unsure just select 
Akonadi and do not specify a subsystem of it or set the subsystem to 
"general" or something like that. The upstream bug tracker is a bit more 
detailed on this.

So if you really like to see your issue fixed, I suggest you invest some 
additional time.

Also see:

"The body of the report" in https://www.debian.org/Bugs/Reporting

In the page there is the recommendation not to report upstream. I can 
say already that this is very, very likely an upstream bug, so you can 
help by creating an upstream report.

In case IMAP is involved also see:

How To Create Useful Bugreports for the Akonadi IMAP Resource

https://community.kde.org/PIM/Akonadi/Debug_IMAP

I thought there would be a generic bug reporting page for Akonadi, but I 
did not find one.

Thanks,
-- 
Martin

Bug#864074: defaults.vim: broken configuration

[Martin Steigerwald]

Dear James.

James McCoy - 06.07.17, 03:09:23 CEST:
> > 3) Vim wordwraps by default now. I wonder about how many admins will
> > break config files with long lines accidently by that new default
> > behaviour.
> I don't see anything in defaults.vim that changes 'textwidth' from its
> default value of 0, so I'm not sure what you're experiencing here.
> Maybe ":verbose set textwidth?" will help next time you run into this
> issue.

Finally I found this one. It is:

% grep filetype /usr/share/vim/vim82/defaults.vim 
" Use the default filetype settings, so that mail gets 'tw' set to 72,
" Revert with ":filetype off".
filetype plugin indent on

It triggers for example for editing Git commit messages. And no, I don't 
like command line output to be wrapped in there.

Thus I did:

% cat /etc/vim/vimrc.local 
[…]
" 'set mouse=' in /etc/vim/vimrc.local is ignored unless ~/.vimrc exists
" https://bugs.debian.org/864074
runtime! defaults.vim
let g:skip_defaults_vim = 1
[…]
:filetype plugin indent off
[…]

Let's hope no other unexpected configuration changes creep in by using 
defaults.vim – otherwise I may reconsider having 'runtime! defaults.vim' 
in 'vimrc.local', so far I am not sure it gives me any substantial 
benefits over just using my own configuration.

I am also not sure whether I really like incremental search so far. 
Let's see.

I am still not convinced that the current handling of 'vimrc.local' is 
Debian user friendly.

Ciao,
-- 
Martin

Bug#854869: Removing REST API not recommended

[Martin Steigerwald]

Hi.

Craig Small - 03.04.20, 02:18:47 CEST:
> WordPress doesn't recommend that sites disable the REST API[1]
> therefore it would cause more problems doing this by default in the
> Debian package. There are a few ways of adjusting the REST API if
> needed.

Fair enough.

I found this out myself as the new block based editor won't work without 
it.

I use the Disable WP REST API plugin meanwhile.

> 1:
> https://developer.wordpress.org/rest-api/frequently-asked-questions/#c
> an-i-disable-the-rest-api

Thanks,
-- 
Martin

Bug#952645: webext-ublock-origin: please consider packaging ublock origin 1.25 or later

[Martin Steigerwald]

Martin Steigerwald - 26.02.20, 21:06:50 CET:
> Package: webext-ublock-origin
> Version: 1.22.2+dfsg-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please consider packaging uBlock Origin 1.25 or later for its
> protection against using CNAME's to bypass ad blockers:
> 
> https://www.ghacks.net/2020/02/26/if-you-run-ublock-origin-use-the-fir
> efox-version-as-it-offers-better-protection/

I am a bit confused about the right minimum version number. The ghacks 
article mentions 1.25. However on Github I find it in 1.41 beta release 
(which would likely not yet suitable for being packaged just yet).

https://github.com/gorhill/uMatrix/releases

Thanks,
Martin

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200,
> 'experimental') Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.5.6-tp520 (SMP w/4 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
> 
> webext-ublock-origin depends on no packages.
> 
> Versions of packages webext-ublock-origin recommends:
> ii  chromium 80.0.3987.116-1
> ii  firefox  73.0.1-1+b1
> ii  firefox-esr  68.5.0esr-1+b1
> 
> Versions of packages webext-ublock-origin suggests:
> ii  ublock-origin-doc  1.22.2+dfsg-1
> 
> -- no debconf information


-- 
Martin

Bug#952645: webext-ublock-origin: please consider packaging ublock origin 1.25 or later

[Martin Steigerwald]

Martin Steigerwald - 26.02.20, 21:19:33 CET:
> Martin Steigerwald - 26.02.20, 21:06:50 CET:
> > Package: webext-ublock-origin
> > Version: 1.22.2+dfsg-1
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > Please consider packaging uBlock Origin 1.25 or later for its
> > protection against using CNAME's to bypass ad blockers:
> > 
> > https://www.ghacks.net/2020/02/26/if-you-run-ublock-origin-use-the-f
> > ir efox-version-as-it-offers-better-protection/
> 
> I am a bit confused about the right minimum version number. The ghacks
> article mentions 1.25. However on Github I find it in 1.41 beta
> release (which would likely not yet suitable for being packaged just
> yet).
> 
> https://github.com/gorhill/uMatrix/releases

Scratch that, this was uMatrix. For uBlock Origin 1.25 seems to be 
right:

https://github.com/gorhill/uBlock/releases

Sorry for the noise.
-- 
Martin

Bug#919557: webext-umatrix: garbled display of toolbar menu in Firefox 64.0-1

[Martin Steigerwald]

Hi!

Is there any update regarding this?

I ponder to switch all web extensions to browser installed ones as I am 
not sure whether it is feasible to expect Debian web extension packages 
to be up-to-date and in a working condition. I'd love to have these 
centrally updated by apt, but it seems it is challenging to get this 
right and there I bet there are only a few people volunteering to 
maintain those Debian packages.

Ciao,
-- 
Martin

Bug#952645: webext-ublock-origin: please consider packaging ublock origin 1.25 or later

[Martin Steigerwald]

Package: webext-ublock-origin
Version: 1.22.2+dfsg-1
Severity: wishlist

Dear Maintainer,

Please consider packaging uBlock Origin 1.25 or later for its protection
against using CNAME's to bypass ad blockers:

https://www.ghacks.net/2020/02/26/if-you-run-ublock-origin-use-the-firefox-version-as-it-offers-better-protection/

Thanks,
Martin

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

Kernel: Linux 5.5.6-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  chromium 80.0.3987.116-1
ii  firefox  73.0.1-1+b1
ii  firefox-esr  68.5.0esr-1+b1

Versions of packages webext-ublock-origin suggests:
ii  ublock-origin-doc  1.22.2+dfsg-1

-- no debconf information

Bug#948719: fio, (build-)dependencies unsatisfiable on mipsel.

[Martin Steigerwald]

Hi Peter!

Thank you for your report.

Am Sonntag, den 12.01.2020, 15:23 + schrieb peter green:
> Package: fio
> Version: 14.2.5-3
> Severity: serious
>
> The binary packages built from the ceph source package were recently
> removed from mipsel, because the new version of ceph runs out of
> address space during the build. Your package build-depends on librbd-
> dev and depends on librbd1 which are built from the ceph source
> package. So fio is now uninstallable and unbuildable on mipsel.
>
> The librbd-dev build-dependency is arch-qualified as linux-any, which
> suggests building with rbd support is optional. If possible please
> build your package without rbd support on mipsel (if this is not
> possible then you will probablly need to request removal of the fio
> packages on mipsel).

I am pretty sure that building with rbd support is optional.

However even after looking at Debian Policy in detail¹ I still do not
know whether:

Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1~), libaio-dev
[linux-any], zlib1g-dev, librdmacm-dev [linux-any], libibverbs-dev
[linux-any], librbd-dev [linux-any !mipsel], libgtk2.0-dev, libcairo2-
dev, libnuma-dev [linux-any], flex, bison, libglusterfs-dev

instead of

Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1~), libaio-dev
[linux-any], zlib1g-dev, librdmacm-dev [linux-any], libibverbs-dev
[linux-any], librbd-dev [linux-any !], libgtk2.0-dev, libcairo2-dev,
libnuma-dev [linux-any], flex, bison, libglusterfs-dev

would work.

What I do not know whether I can first include some architecture
wildcard and then exclude some other architecture. The policy appears to
lack any clear guidance on that. There is also no example in there which
indicates that this is possible.

Just using [!mipsel] would break the build on other architectures like
FreeBSD and Hurd again.

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html

Thanks,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Oliver Kügow •
Richard Müller •
Jonas Hasselberg
 •
Jonas Persson
– Delivering Business Agility –

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Martin Steigerwald]

Package: endless-sky
Version: 0.9.8-1+b1
Severity: wishlist

Dear Michael,

please package version 0.9.10 or whatever version is current when you decide
to do an updated package.

Thanks,
Martin

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

Kernel: Linux 5.4.0-rc7-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages endless-sky depends on:
ii  endless-sky-data  0.9.8-1
ii  libc6 2.29-3
ii  libgcc1   1:9.2.1-19
ii  libgl11.1.0-1+b1
ii  libglew2.12.1.0-4+b1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libmad0   0.15.1b-10
ii  libopenal11:1.19.1-1+b1
ii  libpng16-16   1.6.37-1
ii  libsdl2-2.0-0 2.0.10+dfsg1-1
ii  libstdc++69.2.1-19

endless-sky recommends no packages.

endless-sky suggests no packages.

-- no debconf information

Bug#943344: plasma-workspace: plasmashell with Qt 5.12.5 crashes on any notification

[Martin Steigerwald]

Thread on debian-kde-Mailinglist:

Re: Transition of Qt to 5.12.5

https://lists.debian.org/debian-kde/2019/10/msg00033.html

Luca Pedrielli found this initially. I just reported the bug.

Thanks,
-- 
Martin

Bug#943344: plasma-workspace: plasmashell with Qt 5.12.5 crashes on any notification

[Martin Steigerwald]

Hi!

Probably related:

Bug 1758263 - qt 5-12.5 update pushed to testing causes continual 
crashes 

https://bugzilla.redhat.com/show_bug.cgi?id=1758263


FEDORA-2019-2a4f82aa58

bugfix update in Fedora 30 for analitza, appmenu-qt5, & 81 more 

https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a4f82aa58


According to these an update of qt5-qtdeclarative-5.12.5-3 fixed the 
issue for them. I am currently not sure how to dig out which patch they 
have applied from above reports, and I need a break anyway.

Thanks,
-- 
Martin

Bug#943344: plasma-workspace: plasmashell with Qt 5.12.5 crashes on any notification

[Martin Steigerwald]

Martin Steigerwald - 23.10.19, 18:38:53 CEST:
> Package: plasma-workspace
> Version: 4:5.14.5.1-3+b1
> Severity: important
[…]
> After upgrading to Qt 5.12.5 packages Plasmashell crashes on any
> notification.
> 
> I can reproduce this with:
> 
> kdialog --passivepopup 'text' 5
> 
> Output on Konsole:
> 
> KCrash: Attempting to start /usr/bin/plasmashell from kdeinit
> sock_file=/run/user/1000/kdeinit5__0
> KCrash: crashing... crashRecursionCounter = 2
> KCrash: Application Name = plasmashell path = /usr/bin pid = 6549
> KCrash: Arguments: /usr/bin/plasmashell
> KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
> from kdeinit sock_file=/run/user/1000/kdeinit5__0
> QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
> QSocketNotifier: Invalid socket 23 and type 'Read', disabling...
> QSocketNotifier: Invalid socket 56 and type 'Read', disabling...
> QSocketNotifier: Invalid socket 9 and type 'Read', disabling...
> QSocketNotifier: Invalid socket 28 and type 'Read', disabling...
> zsh: suspended (signal)  plasmashell
> 
> It apparently cannot start DrKonqi.
> 
> I am trying to obtain debug data.

Here is the backtrace I got:

[Thread 0x7fffa37fe700 (LWP 8517) exited]

Thread 1 "plasmashell" received signal SIGSEGV, Segmentation fault.
QObject::setProperty (this=this@entry=0x0, name=name@entry=0x7fffb83f1030 
"sourceName", value=...) at kernel/qobject.cpp:3914
3914kernel/qobject.cpp: Datei oder Verzeichnis nicht gefunden.
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) bt full
#0  0x75b72bb7 in QObject::setProperty(char const*, QVariant const&) 
(this=this@entry=0x0, name=name@entry=0x7fffb83f1030 "sourceName", value=...)
at kernel/qobject.cpp:3914
d = 
meta = 
id = 
p = {mobj = 0x75c1d790 , handle = 136, 
idx = 0, menum = {mobj = 0x11, handle = 3501643008}}
#1  0x7fffb83e7eda in NotificationsHelper::processShow() 
(this=0x598ebc40) at 
./applets/notifications/plugin/notificationshelper.cpp:133
notificationData = {d = 0x562e6130}
sourceName = {static null = {}, d = 0x59165130}
popup = 0x0
#2  0x7fffb83e8da0 in 
NotificationsHelper::displayNotification(QMap const&) 
(this=0x598ebc40, notificationData=...)
at ./applets/notifications/plugin/notificationshelper.cpp:223
sourceName = 
{d = {data = {c = 48 '0', uc = 48 '0', s = 20784, sc = 48 '0', us = 
20784, i = 1494634800, u = 1494634800, l = 93825055215920, ul = 93825055215920, 
b = 48, d = 4.6355736501344133e-310, f = 2.64440707e+15, real = 
4.6355736501344133e-310, ll = 93825055215920, ull = 93825055215920, o = 
0x59165130, ptr = 0x59165130, shared = 0x59165130}, type = 10, 
is_shared = 0, is_null = 0}}
i = 
j = {c = , i = {i = 0x5e063c90}, n = {i = }}
#3  0x7fffb83ef8eb in NotificationsHelper::qt_static_metacall(QObject*, 
QMetaObject::Call, int, void**)
(_o=_o@entry=0x598ebc40, _c=_c@entry=QMetaObject::InvokeMetaMethod, 
_id=_id@entry=9, _a=_a@entry=0x7fff8990)
at 
./obj-x86_64-linux-gnu/applets/notifications/plugin/notificationshelperplugin_autogen/EWIEGA46WW/moc_notificationshelper.cpp:163
_t = 0x598ebc40
#4  0x7fffb83f0293 in NotificationsHelper::qt_metacall(QMetaObject::Call, 
int, void**)
(this=0x598ebc40, _c=QMetaObject::InvokeMetaMethod, _id=9, 
_a=0x7fff8990)
at 
./obj-x86_64-linux-gnu/applets/notifications/plugin/notificationshelperplugin_autogen/EWIEGA46WW/moc_notificationshelper.cpp:231
#5  0x773be9fd in QQmlObjectOrGadget::metacall(QMetaObject::Call, int, 
void**) const
(this=this@entry=0x7fff8cd0, 
type=type@entry=QMetaObject::InvokeMetaMethod, index=, 
index@entry=14, argv=)
at 
../../include/QtQml/5.12.5/QtQml/private/../../../../../src/qml/qml/ftw/qflagpointer_p.h:335
#6  0x772b1b5d in CallMethod(QQmlObjectOrGadget const&, int, int, int, 
int*, QV4::ExecutionEngine*, QV4::CallData*, QMetaObject::Call)
(object=..., index=, returnType=returnType@entry=43, 
argCount=, argTypes=, 
engine=engine@entry=0x55752700, callArgs=, 
callType=) at jsruntime/qv4qobjectwrapper.cpp:1295
args = 
{a = 9, s = 2, ptr = 0x7fff89f0, {array = 
"\000\000\000\000\000\000\000\000\230\230n\355\377\177\000\000\220\230n\355\377\177\000\000\000ն\320\v\276\f]\000\000\000\000\000\200\003\000\060a.VUU\000\000\b",
 '\000' , 
"\030\212\377\377\377\177\000\000\377\377\377\377\377\177\000\000\220\344\216YUU\000\000;36\367\377\177\000\000\000\000\000\000\000\000\000\000`\213\377\377\377\177\000\000@K\266ZUU\000\000~M+\367\377\177\000\000\000'uUUU\000\000\240\215\377\377\377\177\000\000\210\227n\355\377\177\000\000\000ն\320\v\276\f]\001\000\000\000\000\200\003\000\240\215\377\377\377\177\000\000\000\000\000\000\000\000\000\000\060\257\216

Bug#943344: plasma-workspace: plasmashell with Qt 5.12.5 crashes on any notification

[Martin Steigerwald]

Package: plasma-workspace
Version: 4:5.14.5.1-3+b1
Severity: important

Dear Maintainer,

After upgrading to Qt 5.12.5 packages Plasmashell crashes on any notification.

I can reproduce this with:

kdialog --passivepopup 'text' 5

Output on Konsole:

KCrash: Attempting to start /usr/bin/plasmashell from kdeinit
sock_file=/run/user/1000/kdeinit5__0
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = plasmashell path = /usr/bin pid = 6549
KCrash: Arguments: /usr/bin/plasmashell 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from 
kdeinit
sock_file=/run/user/1000/kdeinit5__0
QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
QSocketNotifier: Invalid socket 23 and type 'Read', disabling...
QSocketNotifier: Invalid socket 56 and type 'Read', disabling...
QSocketNotifier: Invalid socket 9 and type 'Read', disabling...
QSocketNotifier: Invalid socket 28 and type 'Read', disabling...
zsh: suspended (signal)  plasmashell

It apparently cannot start DrKonqi.

I am trying to obtain debug data.

Best,
Martin

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

Kernel: Linux 5.3.5-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages plasma-workspace depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.16-2
ii  drkonqi  5.14.5-1
ii  frameworkintegration 5.62.0-1
ii  gdb  8.3.1-1
ii  iso-codes4.4-1
ii  kactivitymanagerd5.14.5-1
ii  kded55.62.0-1
ii  kinit5.62.0-1
ii  kio  5.62.1-2
ii  kpackagetool55.62.0-1
ii  kwin-common  4:5.14.5-1+b1
ii  libappstreamqt2  0.12.9-1
ii  libc62.29-2
ii  libcolorcorrect5 4:5.14.5.1-3+b1
ii  libgcc1  1:9.2.1-12
ii  libgps25 3.19-2
ii  libice6  2:1.0.9-2
ii  libkf5activities55.62.0-1
ii  libkf5authcore5  5.62.0-1
ii  libkf5baloo5 5.62.0-2
ii  libkf5bookmarks5 5.62.0-1
ii  libkf5calendarevents55.62.0-1
ii  libkf5completion55.62.0-1
ii  libkf5config-bin 5.62.0-1
ii  libkf5configcore55.62.0-1
ii  libkf5configgui5 5.62.0-1
ii  libkf5configwidgets5 5.62.0-1
ii  libkf5coreaddons55.62.0-1
ii  libkf5crash5 5.62.0-1
ii  libkf5dbusaddons55.62.0-1
ii  libkf5declarative5   5.62.0-1
ii  libkf5globalaccel-bin5.62.0-1
ii  libkf5globalaccel5   5.62.0-1
ii  libkf5guiaddons5 5.62.0-1
ii  libkf5holidays5  1:5.62.0-1
ii  libkf5i18n5  5.62.0-1
ii  libkf5iconthemes55.62.0-1
ii  libkf5idletime5  5.62.0-1
ii  libkf5itemviews5 5.62.0-1
ii  libkf5jobwidgets55.62.0-1
ii  libkf5js55.62.0-1
ii  libkf5jsembed5   5.62.0-1
ii  libkf5kdelibs4support5   5.62.0-1
ii  libkf5kiocore5   5.62.1-2
ii  libkf5kiofilewidgets55.62.1-2
ii  libkf5kiogui55.62.1-2
ii  libkf5kiowidgets55.62.1-2
ii  libkf5networkmanagerqt6  5.62.0-1
ii  libkf5newstuff5  5.62.0-1
ii  libkf5notifications5 5.62.0-1
ii  libkf5notifyconfig5  5.62.0-1
ii  libkf5package5   5.62.0-1
ii  libkf5plasma55.62.0-1
ii  libkf5plasmaquick5   5.62.0-1
ii  libkf5prison55.62.0-1
ii  libkf5quickaddons5   5.62.0-1
ii  libkf5runner55.62.0-1
ii  libkf5service-bin5.62.0-1
ii  libkf5service5   5.62.0-1
ii  libkf5solid5 5.62.0-2
ii  libkf5texteditor55.62.0-1
ii  libkf5textwidgets5   5.62.0-1
ii  libkf5wallet-bin 

Bug#942537: Please package newer version

[Martin Steigerwald]

Am Montag, den 21.10.2019, 10:01 +0200 schrieb Sven Hoexter:
> On Sun, Oct 20, 2019 at 02:38:28PM +0200, Sven Hoexter wrote:
> > > 2) You can also update it to fio 3.16 and upload that. I would be
> > > okay
> > > with an NMU.
> >
> > I currently look into this option. Since we set it up on Salsa in
> > the
> > Debian group, I can update the package. But let me see if it builds
> > here.
>
> I just uploaded 3.16 and pushed everything to salsa. Had to add a
> small
> oneline fix from upstream to get the gfio stuff to build. The patch
> can
> be removed with 3.17+.
>
> Hope that helps for now, didn't do any polishing of typos.

Thank you very much, Sven. That helps a lot.

Justin, thank you for your understanding.

Have a wonderful week,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Oliver Kügow •
Richard Müller •
Jonas Hasselberg
 •
Jonas Persson
– Delivering Business Agility –

Bug#942537: Please package newer version

[Martin Steigerwald]

Hi Iustin.

Am Donnerstag, den 17.10.2019, 21:14 +0200 schrieb Iustin Pop:
> Package: fio
> Version: 3.12-2
> Severity: wishlist
>
> I reported earlier this year a bug against fio
> (https://github.com/axboe/fio/issues/738) only to find that it was
> long
> fixed upstream, actually. Sid has 3.12, upstream is at 3.16. Could you
> please package a newer version?

I have no time to attend to fio at the moment as I am overloaded with
other things and really need to take care of myself now. This will
likely not change for the next at least two weeks, probably longer.

However… I upgraded the packaging repo for 3.15 quite some time ago
already¹. I did not ask Sven Hoexter, my sponsor, to upload it
immediately cause I was waiting for a merge request regarding:

fio FTCBFS: builds for the build architecture

https://bugs.debian.org/929579


>From here there are several options:

1) Sven or you review the fio 3.15 package and upload it. In case there
are any fixes, please not tough, that I may not have time to apply them
at the moment.

2) You can also update it to fio 3.16 and upload that. I would be okay
with an NMU.

3) You build the fio 3.15 package yourself or I can make the packages I
build available to you.

If 3.15 would be enough for now, I think option 1 would be a good way to
go.

Thank you for your understanding.

[1] For example via gbp clone g...@salsa.debian.org:debian/fio.git

Thanks,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Oliver Kügow •
Richard Müller •
Jonas Hasselberg
 •
Jonas Persson
– Delivering Business Agility –

Bug#941120: akonadi-backend-postgresql: fails to stop postgresql 11

[Martin Steigerwald]

Dear Sandro,

Sandro Knauß - 10.10.19, 20:31:33 CEST:
> Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=386173#c20
[…]
> as I don't use postgresql as backend, can you explain, why this bug it
> that annoying, so I should fix that also for stable?

Hmmm, thinking about it, the case for stable may not be all that strong. 
As I do not use stable, I won't need it there.

I am not sure how many Debian users use stable Akonadi with PostgreSQL 
and PostgreSQL even appears to pick up the running processes after a 
subsequent "akonadictl start". Considering all this, the only annoyance 
and confusion is that some PostgreSQL processes keep lingering around. 
Some users may be confused about this.

Okay, all in all, not all that convincing arguments for stable. I just 
thought if you do all the other fixes, you could put this one in as well. 
I considered it to be low risk.

As the fix is in Akonadi 19.04, you may consider to close the bug right 
away or close it when uploading Akonadi 19.08 or newer packages.

Best,
-- 
Martin

Bug#941118: akonadi-server: fails to start after upgrade to 4:18.08.3-8: apparmor denied access to pg_ctl

[Martin Steigerwald]

Hi intrigeri, Sandro et al,

intrigeri - 05.10.19, 06:04:55 CEST:
> Hi Sandro et al,
> 
> Sandro Knauß:
> > I now pushed a first version of Akonadi with the new AppArmor
> > profile, but as you see down here it fails and I'm not sure, what
> > went wrong. What we need to do to debug this?
> 
> [...]
> 
> >> > I believe the failure may be due to this:
> >> > 
> >> > Sep 25 09:21:06 merkaba kernel: [  266.556167][   T37] audit:
> >> > type=1400 audit(1569396066.434:45): apparmor="DENIED"
> >> > operation="exec" profile="postgresql_akonadi" name="/bin/dash"
> >> > pid=3833 comm="pg_ctl" requested_mask="x" denied_mask="x"
> >> > fsuid=1000
> >> > ouid=0
> 
> https://salsa.debian.org/qt-kde-team/kde/akonadi/blob/master/debian/ap
> parmor/postgresql_akonadi#L12 reads:
> 
>   /usr/bin/dash mrix,
> 
> I believe this only does what you mean on a merged-/usr system.
> I suspect Martin is reporting from a system without merged-/usr.
> Replacing this line with that one should fix this particular problem:
> 
>   /{usr/,}bin/dash mrix,
> 
> Hoping it helps :)

Haha! Indeed. No merged-/usr here and after a time with Systemd now 
running on sysvinit + elogind.

I made this change and did "aa-enforce postgresql_akonadi".

Akonadi starts fine with that.
 
Thank you,
-- 
Martin

Bug#934905: libaqbanking35: libaqbanking not ready for PSD2, will not work after 14 September 2019

[Martin Steigerwald]

Hi.

Alexander Weiss - 04.10.19, 21:22:37 CEST:
> according to https://www.aquamaniac.de/rdm/news/10 at least version
> 5.99.25beta is necessary for PSD2 support.
> (I believe some more bugs are fixed in higher releases)
> 
> Is it planned to get one of the (really) PSD2-ready versions to
> unstable or even testing (even better: buster-backports) in the near
> future?

Please refer to

Bug#940136: aqbanking-tools: Transaction fails with 9075::Starke 
Kundenauthentifizierung notwendig.

https://bugs.debian.org/934905

Thanks
-- 
Martin

Bug#940136: aqbanking-tools: Transaction fails with 9075::Starke Kundenauthentifizierung notwendig.

[Martin Steigerwald]

Dear Micha.

Micha Lenk - 03.10.19, 20:27:48 CEST:
> I started to look into updating AqBanking in Debian again. It all
> starts with uploading Gwenhywfar, which I did a few days ago. As
> usual when binary package names change (in this case required due to
> the soname bump), the package is currently stalled in the NEW queue.
> https://ftp-master.debian.org/new/libgwenhywfar_4.99.19rc3-1.html
> 
> So we will need some patience now.

Thank you very much. Looking forward to it.

Best,
-- 
Martin

Bug#940136: aqbanking-tools: Transaction fails with 9075::Starke Kundenauthentifizierung notwendig.

[Martin Steigerwald]

Package: libaqbanking35
Version: 5.8.2-0.1
Followup-For: Bug #940136

Dear Micha, dear Felix, dear reader,

I can confirm this regarding KMyMoney.

Yes, AQBanking 6 is still beta, but meanwhile there are tarballs on the
upstream site.

https://www.aquamaniac.de/rdm/projects/aqbanking/files

As of today currently it is:

https://www.aquamaniac.de/rdm/attachments/download/174/aqbanking-5.99.38beta.tar.gz

I read in AQBanking user mailing list that KMyMoney 5.0.7 requires at least
5.99.32 beta.

AFAIR Micha told he does not have much time at the moment. I will be quite
busy in the next weeks as well and would need to did into how AQBanking Debian
packaging is done first. Anyone willing to package it who also manages to
take the time for it?

Thank you,
Martin

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

Kernel: Linux 5.2.16-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libaqbanking35 depends on:
ii  libaqbanking-data  5.8.2-0.1
ii  libc6  2.29-2
ii  libgmp10   2:6.1.2+dfsg-4
ii  libgwenhywfar604.20.2-1

Versions of packages libaqbanking35 recommends:
ii  libaqbanking35-plugins  5.8.2-0.1

Versions of packages libaqbanking35 suggests:
ii  aqbanking-tools  5.8.2-0.1

-- no debconf information

Bug#941118: akonadi-server: fails to start after upgrade to 4:18.08.3-8: apparmor denied access to pg_ctl

[Martin Steigerwald]

Martin Steigerwald - 25.09.19, 09:32:15 CEST:
> Package: akonadi-server
> Version: 4:18.08.3-8
> Severity: important
[…]
> I upgraded and then rebooted the system.
> 
> After upgrading to Akonadi 4:18.08.3-8, Akonadi does not start
> anymore:
> 
> % akonadictl start
> Connecting to deprecated signal
> QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString
> ) org.kde.pim.akonadicontrol: Application 'akonadiserver' exited
> normally...
> 
> I believe the failure may be due to this:
> 
> Sep 25 09:21:06 merkaba kernel: [  266.556167][   T37] audit:
> type=1400 audit(1569396066.434:45): apparmor="DENIED"
> operation="exec" profile="postgresql_akonadi" name="/bin/dash"
> pid=3833 comm="pg_ctl" requested_mask="x" denied_mask="x" fsuid=1000
> ouid=0
[…]
> Also setting to complain mode does not help:
> 
> % aa-complain postgresql_akonadi
> Setting /etc/apparmor.d/postgresql_akonadi to complain mode.
> 
> Although access does get allowed then:
> 
> Sep 25 09:30:14 merkaba kernel: [  814.345508][   T37] audit:
> type=1400 audit(1569396614.227:51): apparmor="ALLOWED"
> operation="exec" profile="postgresql_akonadi" name="/bin/dash"
> pid=5328 comm="pg_ctl" requested_mask="x" denied_mask="x" fsuid=1000
> ouid=0 target="postgresql_akonadi//null-/bin/dash"

Oh, it does help. Akonadi starts again, just did not notice it 
initially.

The pattern in

% grep pg_ctl /etc/apparmor.d/postgresql_akonadi
  /usr/lib/postgresql/*/bin/pg_ctl mrix,
 
seems to be okay tough:

% ls -l /usr/lib/postgresql/*/bin/pg_ctl
-rwxr-xr-x 1 root root 59888 Sep 24 22:09 /usr/lib/postgresql/11/bin/
pg_ctl

However I am no AppArmor expert…

Best,
-- 
Martin

Bug#941120: akonadi-backend-postgresql: fails to stop postgresql 11

[Martin Steigerwald]

Package: akonadi-backend-postgresql
Version: 4:18.08.3-8
Severity: normal

Dear Sandro,

you may like to consider

Git commit 565700f7fc1d73e337600109867fc01cc647cf13 by Daniel Vrátil.
Committed on 20/06/2019 at 09:51.
Pushed by dvratil into branch 'Applications/19.04'.

Check Postgres status by checking return code of pg_ctl

Summary:
The current code which was checking the standard output of "pg_ctl status",
doesn't work with non-English locale, causing Akonadi to leave Postgres
running after shutdown, because it thinks the db is no longer running.
FIXED-IN: 5.11.3

https://bugs.kde.org/show_bug.cgi?id=386173#c20

for Akonadi for buster.

Thanks,
Martin

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

Kernel: Linux 5.2.16-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages akonadi-backend-postgresql depends on:
ii  libqt5sql5-psql  5.11.3+dfsg1-4

Versions of packages akonadi-backend-postgresql recommends:
ii  akonadi-server  4:18.08.3-8
ii  postgresql  11+207

akonadi-backend-postgresql suggests no packages.

-- no debconf information

Bug#941118: akonadi-server: fails to start after upgrade to 4:18.08.3-8: apparmor denied access to pg_ctl

[Martin Steigerwald]

Package: akonadi-server
Version: 4:18.08.3-8
Severity: important

Dear Sandro,

I was tempted to raise severity to grave, but then thought that this may
just happen on my system. Severity can still be raised if it happens on
other systems as well. It may refuse to start on all setups using
PostgreSQL backend, see below.

I upgraded and then rebooted the system.

After upgrading to Akonadi 4:18.08.3-8, Akonadi does not start anymore:

% akonadictl start
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally...

I believe the failure may be due to this:

Sep 25 09:21:06 merkaba kernel: [  266.556167][   T37] audit: type=1400 
audit(1569396066.434:45): apparmor="DENIED" operation="exec" 
profile="postgresql_akonadi" name="/bin/dash" pid=3833 comm="pg_ctl" 
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

However when I use:

% aa-disable postgresql_akonadi
Disabling /etc/apparmor.d/postgresql_akonadi.

I can still not start Akonadi – same console output as before, syslog output:

Sep 25 09:27:17 merkaba kernel: [  637.670793][   T37] audit: type=1400 
audit(1569396437.550:46): apparmor="STATUS" operation="profile_remove" 
profile="unconfined" name="postgresql_akonadi" pid=5247 comm="apparmor_parser"
Sep 25 09:27:26 merkaba kernel: [  647.098937][   T37] audit: type=1400 
audit(1569396446.978:47): apparmor="DENIED" operation="exec" info="profile 
transition not found" error=-13 profile="/usr/bin/akonadiserver" 
name="/usr/lib/postgresql/11/bin/pg_ctl" pid=5261 comm="akonadiserver" 
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Also setting to complain mode does not help:

% aa-complain postgresql_akonadi
Setting /etc/apparmor.d/postgresql_akonadi to complain mode.

Although access does get allowed then:

Sep 25 09:30:14 merkaba kernel: [  814.345508][   T37] audit: type=1400 
audit(1569396614.227:51): apparmor="ALLOWED" operation="exec" 
profile="postgresql_akonadi" name="/bin/dash" pid=5328 comm="pg_ctl" 
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 
target="postgresql_akonadi//null-/bin/dash"

Best,
Martin


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

Kernel: Linux 5.2.16-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages akonadi-server depends on:
ii  akonadi-backend-postgresql   4:18.08.3-8
ii  libc62.29-2
ii  libgcc1  1:9.2.1-8
ii  libkf5akonadiprivate5abi2 [libkf5akonadiprivate5-18.08]  4:18.08.3-8
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-18.08]  4:18.08.3-8
ii  libkf5configcore55.62.0-1
ii  libkf5coreaddons55.62.0-1
ii  libkf5crash5 5.62.0-1
ii  libkf5i18n5  5.62.0-1
ii  libqt5core5a 5.11.3+dfsg1-4
ii  libqt5dbus5  5.11.3+dfsg1-4
ii  libqt5gui5   5.11.3+dfsg1-4
ii  libqt5network5   5.11.3+dfsg1-4
ii  libqt5sql5   5.11.3+dfsg1-4
ii  libqt5widgets5   5.11.3+dfsg1-4
ii  libqt5xml5   5.11.3+dfsg1-4
ii  libstdc++6   9.2.1-8

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
pn  akonadi-backend-mysql   
ii  akonadi-backend-postgresql  4:18.08.3-8
pn  akonadi-backend-sqlite  

-- no debconf information

Bug#940966: [qml-module-org-kde-kirigami2] qml-module-org-kde-kirigami2 uses an invalid version of QtQuick.Controls

[Martin Steigerwald]

Hi!

Ximo Baldó i Soriano - 24.09.19, 19:49:56 CEST:
> Package: qml-module-org-kde-kirigami2
> Version: 5.62.0-1
> 
> --- Please enter the report below this line. ---
> 
> It affects other parts of 'look and feel'  from systemsettings, no
> only wallpaper selection. For now, as far I know, no one is working
> but color schemes.

Please check whether this is fixed in 5.62.0-2 version of the package.

Thanks,
-- 
Martin

Bug#940939: Upstream

[Martin Steigerwald]

Hi Matthieu.

Matthieu Gallien - 22.09.19, 18:52:07 CEST:
> I have open https://phabricator.kde.org/D22974 to propose a solution.

Thanks.

Okay. As far as I understand this is about Qt 5.11 compatibility. Qt 
5.12.5 will likely land in Debian soon as far as I am aware.

Best,
-- 
Martin

Bug#940223: kmymoney: please update to 5.0.6 so KMyMoney uses registration code for PSD2

[Martin Steigerwald]

Package: kmymoney
Version: 5.0.5-1
Severity: important

Dear Pino,

Starting from today KMyMoney 5.0.5 HBCI/FinTS stopped working with one
banking institute I have an account with, due to new PSD 2 regulations:

HBCI: 3075 - Banking-Programm muss zum 14.09.2019 auf PSD2 umgestellt werden. 
(M)
HBCI: 3079 - Bitte wenden Sie sich an den Hersteller des Banking-Programms. (S)
HBCI: 9078 - Dialog abgebrochen - Banking-Programm ist nicht registriert. (S)

This basically means that the HBCI transaction has been aborted by the
banking server cause KMyMoney is not registered.

PSD 2 requires banking applications to be registered, i.e. so send an
registration code. AQBanking 5.8.2 allows for that. But only KMyMoney 5.0.6
actually uses that new features. That does not really give any security,
since it is just a number being transferred, but it is required by PSD 2.

So please update the packaging of KMyMoney to 5.0.6. In case you need
someone to test before uploading to the archive, please let me know.

Some banking institutes also require a second factor during authentication
already or will do so soon, a TAN number usually. This AFAIK is not yet
implemented in the current stable AQBanking version. I do not know whether
this also needs some changes in KMyMoney. So there may be further updates
required as they become available, but updating to 5.0.6 already allows
KMyMoney HBCI/FinTS transfer to work with some of the banking institutes
again that currently forbid it.

All of this of course means that with Debian Buster HBCI/FinTS will stop
working with more and more banking institutes unless backports are provided.
However I fully understand and appreciate that backports would be quite
some additional work for a small team, or basically just you working on the
package. I personally do not need backports as I use Debian Sid.

(I am not a fan of PSD 2, not at all, but that is off topic for this bug
report.)

Thank you very much,
Martin

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

Kernel: Linux 5.2.13-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages kmymoney depends on:
ii  kio   5.54.1-1
ii  kmymoney-common   5.0.5-1
ii  libalkimia5-7 7.0.2-2
ii  libaqbanking355.8.2-0.1
ii  libaqbanking35-plugins5.8.2-0.1
ii  libc6 2.29-1
ii  libgcc1   1:9.2.1-8
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgpgmepp6   1.13.1-1
ii  libgwengui-cpp0   4.20.0-9
ii  libgwengui-qt5-0  4.20.0-9
ii  libgwenhywfar60   4.20.0-9
ii  libical3  3.0.5-2
ii  libkchart22.6.1-1
ii  libkf5activities5 5.54.0-1
ii  libkf5akonadicore5abi24:18.08.3-7
ii  libkf5archive55.54.0-1
ii  libkf5codecs5 5.54.0-1
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-2
ii  libkf5configgui5  5.54.0-2
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5contacts5   4:18.08.3-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5holidays5   1:5.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5identitymanagement5 18.08.3-2
ii  libkf5itemmodels5 5.54.0-1
ii  libkf5itemviews5  5.54.0-1
ii  libkf5jobwidgets5 5.54.0-1
ii  libkf5kcmutils5   5.54.0-1
ii  libkf5kiocore55.54.1-1
ii  libkf5kiofilewidgets5 5.54.1-1
ii  libkf5kiogui5 5.54.1-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5notifications5  5.54.0-1
ii  libkf5service-bin 5.54.0-1
ii  libkf5service55.54.0-1
ii  libkf5sonnetui5   5.54.0-1
ii  libkf5textwidgets55.54.0-1
ii  libkf5wallet-bin  5.54.0-1
ii  libkf5wallet5 5.54.0-1
ii  libkf5webkit5 5.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libofx7   1:0.9.14-1
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg1-4
ii  libqt5dbus5   5.11.3+dfsg1-4
ii  libqt5gui55.11.3+dfsg1-4
ii  libqt5network55.11.3+dfsg1-4
ii  libqt5printsupport5   5.11.3+dfsg1-4
ii  libqt5quickwidgets5   5.11.3-4
ii  

Bug#935031: konsoles started with KDE are black first

[Martin Steigerwald]

Hi Marc.

Marc Haber - 18.08.19, 13:26:51 CEST:
> Package: konsole
> Version: 4:19.08.0-1
> Severity: normal
> 
> Hi,
> 
> this is a regression that came with the update to 19.08.0
> 
> I have a number of konsoles that open automatically with KDE. I think
> this is a (wanted) feature of the saved session.
> 
> Since today's update, those konsoles are black. Window titla and Menu
> bar are there but no contents. When I open a new tab using
> Ctrl-Shift-T, the konsole becomes usable.

Thank you for your report. Its also discussed in debian-kde mailinst 
list. One observations from there:

It does seem to happen with Konsole windows opened with the session, but 
it does not seem to happen with a newly opened Konsole window.

One idea I have about this that due to the rework of the tabbing 
mechanism which is available to split both horizontally and vertically 
at the same time now it may be that Konsole 19.08 would need a newer 
version of KDE Frameworks than what is packaged in Debian now. So the 
issue may go away once KDE Frameworks is updated in Debian. For now that 
is only guesswork, but application feature development often happens 
with within the application and the frameworks it it using and I am not 
sure whether every time the version dependency is updated by upstream 
developers.

[1] Konsole empty
https://lists.debian.org/debian-kde/2019/08/msg00022.html

Thanks.
-- 
Martin

Bug#931483: konsole: Konsole will not launch from mate-panel or from KDE Application Launcher.

[Martin Steigerwald]

Hi David.

Well as Maxy could not reproduce it and it is no issue for you anymore, 
I'd rather wait whether there someone else has the same issue. It could 
be reopened then or a new bug reported.

I see no real benefit in keeping a bug open cause it *may* be relevant to 
someone else. Let's see whether it is actually an issue for some else.

If that is okay with you, there is no need to reply.

BTW Debian has already been released as Debian 10 aka Buster. But let's 
not discuss other issues with sound cards or whatever else in this bug 
report, there is always debian-kde mailing list you can ask about help 
with issues you have¹. Please for bug reports always keep focused on the 
original issue.

[1] https://lists.debian.org/debian-kde/

Best,
Martin


D.J.J. Ring, Jr. - 16.08.19, 22:18:08 CEST:
> Martin,
> 
> It is only working because I installed Arch Linux and I'm not running
> Debian because of the problems with getting sound card detected with
> the Debian installer. I'll wait until the release.
> 
> So maybe this bug should stay, but I cannot help because I am not
> using Debian now because I cannot run espeak-ng in console and that's
> important to me.
[…]
-- 
Martin

Bug#933598: marked as done (Most extensions now crash upon browser start)

[Martin Steigerwald]

Dear Michael!

Debian Bug Tracking System - 03.08.19, 19:15:08 CEST:
> Your message dated Sat, 03 Aug 2019 17:13:41 +
> with message-id 
> and subject line Bug#933598: fixed in chromium 76.0.3809.87-2
> has caused the Debian Bug report #933598,
> regarding Most extensions now crash upon browser start
> to be marked as done.

Thank you very much for the timely fix on this issue.

I really appreciate it.

Have a wonderful rest of the weekend.
-- 
Martin

Bug#929579: fio FTCBFS: builds for the build architecture

[Martin Steigerwald]

Hi Helmut.

Am Montag, den 27.05.2019, 09:47 +0200 schrieb Martin Steigerwald:
> Helmut Grohne - 26.05.19, 16:22:
> > Source: fio
> > Version: 3.12-2
[…]
> > fio fails to cross build from source, because it configures for the
> > build architecture. fio's configure is very different from autotools
> > and requires the user to export a variable called CROSS_COMPILE.
> > Even
> > then, it uses the wrong pkg-config and runs compiled executables.
> > The
> > attached patch makes fio cross buildable. Please consider applying
> > it.
[…]
> It appears to me that your change would make sense for upstream to
> consider, as according to you there is a bug with cross building in
> fio's own configure logic.  If so it might make the most sense to
> propose the change to upstream via f...@vger.kernel.org (cc to Jens
> Axboe  and me please), in order to keep the Debian
> diff to a minimum. Especially as your patch changes several non-
> consecutive lines.
[…]
> According to the debdiff your patch does not contain a Author: and
> Description: line. Please add those.
>
> Please consider issuing a merge request for your change then¹.
[…]

I updated the packaging to fio-3.15 which should contain the patches you
submitted to upstream.

Please provide a merge request for the Debian specific changes that are
needed to enable cross-building. In case you need to make Debian
specific changes to the upstream source code, please make sure your
patch contains Author: and Descripton: lines.

Please document your changes in the changelog under your name.

Please also test cross building before submitting your merge request.

The package uses git-buildpackage so please use 'gbp clone' to clone the
repository and branch from 'master' branch to generate your merge
request, which should contain only changes in 'debian' directory.

> [1] https://salsa.debian.org/debian/fio

Thanks,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Oliver Kügow •
Richard Müller •
Jakob Høholdt
 •
Peter Mikael Javestad
– Delivering Business Agility –

Bug#933598: Most extensions now crash upon browser start

[Martin Steigerwald]

Hi!

Confirmed.

Downgrading to chromium 76.0.3809.71-1 fixes the issue.

I believe it would be good to raise the severity of the bug so that apt-
listbugs notices it, but as one can argue that the browser is still 
usable without extentions and the package does not violate the debian 
policy, it would be up to the maintainer, the Debian Chromium Team, to 
set the severity to "serious". It could help to avoid duplicate bug 
reports tough.

Best,
-- 
Martin

Bug#932721: webext-https-everywhere: error loading extension: wasm/https_everywhere_lib_wasm.js could not be read

[Martin Steigerwald]

Package: webext-https-everywhere
Version: 2019.6.27-1
Severity: normal

Dear Maintainer,

since some days when I start chromium I get:

Fehler beim Laden der Erweiterung aus: /usr/share/webext/https-everywhere.
Hintergrundskript "wasm/https_everywhere_lib_wasm.js" konnte nicht geladen
werden.

which means in english:

Error while loading extension from: /usr/share/webext/https-everywhere.
Background script "wasm/https_everywhere_lib_wasm.js" could not be loaded.

Indeed the file does not appear to be there:

find /usr/share/webext/https-everywhere/ -iname https_everywhere_lib_wasm.js

returns nothing. There is not even a "wasm" directory within
"/usr/share/webext/https-everywhere".

Firefox loads the extension just fine.

Thanks,
Martin

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

Kernel: Linux 5.2.2-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

webext-https-everywhere depends on no packages.

Versions of packages webext-https-everywhere recommends:
ii  chromium 76.0.3809.62-1
ii  firefox  68.0.1-2
ii  firefox-esr  60.8.0esr-1

webext-https-everywhere suggests no packages.

-- no debconf information

Bug#911844: okular: Prints to the wrong printer

[Martin Steigerwald]

Michael Weghorn - 15.06.19, 23:52:
> On 11/06/2019 23.37, Martin Steigerwald wrote:
> > Hmmm, so it works okay with okular 19.04.1.
> > 
> > That means somewhere between 17.12 and 19.04.1 is a bug fix for the
> > issue you reported. Maybe upstream has an idea which one it might
> > be. At this point I believe all that could be done would be to find
> > and then backport that fix, as Debian is in deep freeze and
> > packaging 19.04 thus out of scope.
> 
> I've investigated a bit and it's not an Okular issue, but one in the
> Qt print dialog with printers that don't have PPD files. It can be
> reproduced e.g. with kate just the same and Brian even mentioned in
> the initial report that qpdfview is affected as well.
> 
> The issue has been fixed upstream (qtbase) with the following commit
> (so that's what would have to be backported):
> 
> 
> commit 84cc8d0badb4abc3c9a96d59c61dddce916a216c
> Author: Albert Astals Cid 
> Date:   Mon Feb 5 09:20:20 2018 +0100
> 
> cups: Support raw printers
> 
> They don't have a ppd but we don't *really* need a ppd to just
> print
> 
> Change-Id: Idf6b6dafc19420a511b057194488e2170cae4d70
> 
> 
> This probably also fixes #911702, but I didn't test that explicitly.

Michael, thank you are lot for your research which made that bug report 
actionable.

Of course there may be another bug in there: When one printer cannot be 
used for some reason, it should not automatically switch to another one. 
But nonetheless the commit you pointed out looks like it can really help 
here.

Best,
-- 
Martin

Bug#930168: Unreproducible on clean installation

[Martin Steigerwald]

Martin Steigerwald - 12.06.19, 22:01:
> Also please note that Kali Linux is not Debian GNU/Linux. So please
> retest any issue you have with Kali Linux with a pure Debian GNU/Linux
> install before reporting it here.
> 
> So please retest with a pure Debian GNU/Linux installation. If you
> cannot reproduce the issue there, I'd close it.

If its reproducible on a Debian GNU/Linux installation even when it does 
not happen all of the time, the bug will stay open of course.

In that case I kindly ask you to research upstream bug tracker for 
similar issues. There has been a lot of bug fixes regarding discover 
since version 5.14.5. So it would help if you could find the bug there if 
its reported and if there is a fix for it, tell us about it. That way you 
can help the understaffed Debian Qt/KDE team fix the bug by adding a patch 
for the 5.14.5 version currently packaged in Debian.

-- 
Martin

Bug#930168: Unreproducible on clean installation

[Martin Steigerwald]

severity 930168 important
tags 930168 moreinfo
thanks

Alexander Kernozhitsky - 12.06.19, 19:05:
> I just tried to install fresh Debian Buster on a VM and tried to
> reproduce the bug. It appears that Discover works fine on a clean
> install.
> 
> As I mentioned before, I am able to reproduce this with AppStream
> metadata manually disabled in APT configs. So this may be the reason.
> 
> Please lower the severity.

Thanks, Alexander. Doesn’t happen here either on a highly customized 
Debian Sid installation.

Lowering severity.

P D, thank you for your report. "renders package unusable" is not the 
right severity if the package is just unusable for you. It is the right 
severity if it makes the package unusable on most of all Debian 
installations. This is certainly not the case here.

So please do not use a release critical bug severity if it is not 
appropriate¹.

Also please note that Kali Linux is not Debian GNU/Linux. So please 
retest any issue you have with Kali Linux with a pure Debian GNU/Linux 
install before reporting it here.

So please retest with a pure Debian GNU/Linux installation. If you 
cannot reproduce the issue there, I'd close it.

[1] https://release.debian.org/testing/rc_policy.txt

Thanks,
-- 
Martin

Bug#911844: okular: Prints to the wrong printer

[Martin Steigerwald]

Martin Steigerwald - 11.06.19, 23:37:
> > I used the neon-user-20190606-1138.iso (okular 19.04.1). Everything
> > behaved normally. No observed bug there. Okular 18.04 from
> > experimental wouldn't install because of unmet depenencies. Another
> > time, perhaps.
> 
> Hmmm, so it works okay with okular 19.04.1.
> 
> That means somewhere between 17.12 and 19.04.1 is a bug fix for the
> issue you reported. Maybe upstream has an idea which one it might be.
> At this point I believe all that could be done would be to find and
> then backport that fix, as Debian is in deep freeze and packaging
> 19.04 thus out of scope.

Well it would be helpful to test with versions in between.

So in case you are still having fun with that, Brian, that would be 
something you could do :). One way might be to test with Ubuntu live 
systems of different versions. Another way would be to build the thing 
yourself and do a git bisect. But well maybe upstream has an idea.

-- 
Martin

Bug#911844: okular: Prints to the wrong printer

[Martin Steigerwald]

Hi Brian.

Brian Potkin - 11.06.19, 21:13:
> On Tue 11 Jun 2019 at 13:20:40 +0200, Martin Steigerwald wrote:
> > Brian Potkin - 11.06.19, 10:42:
> > > On Tue 11 Jun 2019 at 09:53:50 +0200, Martin Steigerwald wrote:
> > […]
> > 
> > > > Two ways to use your (and our) time in a more productive manner
> > > > are:
> > > > 
> > > > 1) Retest with Okular 18.04 from Debian experimental (in case
> > > > you
> > > > run
> > > > buster/sid). Or start KDE Neon in a machine and try with the
> > > > newest
> > > > Okular available there.
> > > 
> > > There might be time for me to do both of these today or tomorrow.
> > 
> > Wonderful.
> 
> And good fun.

Thank you for your contribution.

> I used the neon-user-20190606-1138.iso (okular 19.04.1). Everything
> behaved normally. No observed bug there. Okular 18.04 from
> experimental wouldn't install because of unmet depenencies. Another
> time, perhaps.

Hmmm, so it works okay with okular 19.04.1.

That means somewhere between 17.12 and 19.04.1 is a bug fix for the issue 
you reported. Maybe upstream has an idea which one it might be. At this 
point I believe all that could be done would be to find and then backport 
that fix, as Debian is in deep freeze and packaging 19.04 thus out of 
scope.

Thanks,
-- 
Martin

Bug#911844: okular: Prints to the wrong printer

[Martin Steigerwald]

Brian Potkin - 11.06.19, 10:42:
> On Tue 11 Jun 2019 at 09:53:50 +0200, Martin Steigerwald wrote:
[…]
> > Two ways to use your (and our) time in a more productive manner are:
> > 
> > 1) Retest with Okular 18.04 from Debian experimental (in case you
> > run
> > buster/sid). Or start KDE Neon in a machine and try with the newest
> > Okular available there.
> 
> There might be time for me to do both of these today or tomorrow.

Wonderful.

> > 2) Remind upstream in a friendly way to have a look at the issue.
> > Once there is a patch upstream it is very likely it could be
> > backported for buster. Maybe it would be an idea to raise the
> > upstream bug to KDE's security team.
> 
> You seem to have done that. Thanks.

Yes, appeared to be the quickest way to more this forward for me.

There is a reply by Albert already. He is member of KDE security team 
and AFAIK also develops on Okular. Please review his comments there and 
answer accordingly. It appears he does not yet understand on how to 
reproduce. Maybe, if you can, give a concrete example with the necessary 
CUPS commands or probably an example configuration file.

Thank you very much.

Best,

Bug#911844: okular: Prints to the wrong printer

[Martin Steigerwald]

forwarded 911844 https://bugs.kde.org/402015
thanks
-- 
Martin

Bug#911844: okular: Prints to the wrong printer

[Martin Steigerwald]

severity: important
thanks

Hi Brian,

Brian Potkin - 10.06.19, 21:32:
> Severity: critical
> thanks
> 
> On Thu 25 Oct 2018 at 12:50:25 +0100, Brian Potkin wrote:
> > Package: okular
> > Version: 4:17.12.2-2
> > Severity: critical
> > Tags: upstream security
> > 
> > 
> > 
> > "critical" because a document should always go to where it is sent.
> > Please reduce the severity if I have overestimated the security
> > implications.
> > 
> > The CUPS version being used is 2.2.8-5 and cups-browsed is not
> > running. The issue was encountered while taking another look at
> > #911702.> 
[…]
> > The job is always sent to a local queue when its destination
> > precedes
> > realq_desktop alphabetically.
[…]
> I have retested this. There is no change on the present unstable. I
> cannot see why a confidential print job going to a staff printer is
> anything but a security issue. Maybe this is something that merits
> the tag of normal but explanations are in short supply.

Brian, before raising a bug severity to the highest severity possible, 
please read and understand the Debian's release team guidelines 
regarding release critical bugs¹ as well as the general descriptions of 
bug severities².

A "critical" bug is a bug that introduces a (remotely exploitable) 
security hole on systems you install the package to. A "grave" bug is a 
bug that introduces a (remotely exploitable) security hole allowing 
access to the accounts of users using the package.

None of this is the case here.

If at all, the bug might be "serious" if in the maintainers opinion it 
would make the package unsuitable for release.

Now please respect the reduced bug severity. Raising the severity again 
won't get you any priority handling with an already understaffed Debian 
Qt/KDE team. This is a community of people who are mostly doing unpaid 
work.


Two ways to use your (and our) time in a more productive manner are:

1) Retest with Okular 18.04 from Debian experimental (in case you run 
buster/sid). Or start KDE Neon in a machine and try with the newest 
Okular available there.

2) Remind upstream in a friendly way to have a look at the issue. Once 
there is a patch upstream it is very likely it could be backported for 
buster. Maybe it would be an idea to raise the upstream bug to KDE's 
security team.


[1] https://release.debian.org/testing/rc_policy.txt

[2] https://www.debian.org/Bugs/Developer

Thanks,
-- 
Martin

Bug#929579: [PATCH 1/2] configure: apply ${cross_prefix} to pkg-config calls

[Martin Steigerwald]

Hi Jens, hi Helmut,

(unfortunately our signature software seems to add HTML to the mail and 
vger.kernel.org rejects the mail then… so it won't appear on fio mailing 
list. This is nothing I can influence from my mail client.)

Jens Axboe - 27.05.19, 22:51:
> On 5/27/19 1:32 PM, Helmut Grohne wrote:
> > Otherwise, we're searching for build architecture libraries which is
> > not what we want.
> 
> Applied 1-2, thanks.

Thanks.

When there is a new fio release I update the package and am ready to 
apply/merge the Debian related parts of the cross build changes.

Ciao,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Oliver Kügow •
Richard Müller •
Jakob Høholdt
 •
Peter Mikael Javestad
– Delivering Business Agility –

Bug#929579: fio FTCBFS: builds for the build architecture

[Martin Steigerwald]

Hello Helmut,

Helmut Grohne - 26.05.19, 16:22:
> Source: fio
> Version: 3.12-2
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> fio fails to cross build from source, because it configures for the
> build architecture. fio's configure is very different from autotools
> and requires the user to export a variable called CROSS_COMPILE. Even
> then, it uses the wrong pkg-config and runs compiled executables. The
> attached patch makes fio cross buildable. Please consider applying
> it.

Thank you for your bug report and your patch.

It appears to me that your change would make sense for upstream to 
consider, as according to you there is a bug with cross building in fio's 
own configure logic.  If so it might make the most sense to propose the 
change to upstream via f...@vger.kernel.org (cc to Jens Axboe 
 and me please), in order to keep the Debian diff to a 
minimum. Especially as your patch changes several non-consecutive lines.


Otherwise and probably interim I would carry the change in the package:

According to the debdiff your patch does not contain a Author: and 
Description: line. Please add those.

Please consider issuing a merge request for your change then¹.


I do not consider this change to be important enough to warrant a freeze 
exception for Buster.

[1] https://salsa.debian.org/debian/fio

Thank you,

Mit freundlichen Grüßen / With kind regards
Martin Steigerwald •
Proact Deutschland GmbH
Trainer
Telefon: +49 911 30999 0 •
Fax: +49 911 30999 99
Südwestpark 43 •
90449 Nürnberg •
Germany
martin.steigerw...@proact.de •
www.proact.de
Amtsgericht Nürnberg
 •
HRB 18320
Geschäftsführer:
Oliver Kügow •
Richard Müller •
Jakob Høholdt
 •
Peter Mikael Javestad
– Delivering Business Agility –

Bug#925337: webext-ublock-origin: deactivated with Firefox 66

[Martin Steigerwald]

Markus Koschany - 23.03.19, 23:43:
> [...]
> 
> > I will update ublock-origin to version 1.18.10 and see if it fixes
> > the problem. I couldn't find a hint in the recent release notes, so
> > it could also be a Firefox bug. I will investigate. Since Debian is
> > currently in a full freeze mode and prepares to release Debian 10
> > "Buster" and the bug also doesn't seem to affect the release, I
> > will upload the new version to experimental.
> 
> I have updated ublock-origin to 1.18.10 but the problem still remains.
> However I can confirm that the addon works in chromium 72.x (1.18.4
> and 1.18.10). The official version from the Mozilla store (currently
> 1.18.6) works also fine in Firefox. At the moment I don't know why
> there is a regression in Firefox 66.

Thank you for your prompt reaction and for letting us know.

Would it make sense to reassign this issue to Firefox package so the 
maintainers of it can have a look at?

Thanks,
-- 
Martin

Bug#925337: webext-ublock-origin: deactivated with Firefox 66

[Martin Steigerwald]

Package: webext-ublock-origin
Version: 1.18.4+dfsg-2
Severity: normal

Dear Markus,

uBlock Origin becomes deactivated with Firefox 66.0-1.

With Firefox ESR 60.6.0esr-1 it works okay.

With Firefox 65 it also worked.

Maybe the extension needs an update.

In Buster AFAIK there will only be Firefox ESR. So there does not seem
to be a need to have an updated version in Buster. But for those users
who use Debian Unstable an updated version in experimental would ne nice.

Thanks,
Martin

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

Kernel: Linux 5.0.0-tp520 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  chromium 73.0.3683.75-1
ii  firefox  66.0-1
ii  firefox-esr  60.6.0esr-1

Versions of packages webext-ublock-origin suggests:
ii  ublock-origin-doc  1.18.4+dfsg-2

-- no debconf information

Bug#919557: [Pkg-mozext-maintainers] Bug#919557: webext-umatrix: garbled display of toolbar menu in Firefox 64.0-1

[Martin Steigerwald]

Hi Ximin.

Ximin Luo - 22.02.19, 08:47:
> Control: block -1 by 922944
> 
> Martin Steigerwald:
> > Package: webext-umatrix
> > Version: 1.3.14+dfsg-2
> > Severity: important
> > 
> > Dear Ximin,
> > 
> > I just installed webext-umatrix and found that its control panel
> > does not show up correctly in Firefox. I attach a screenshot.
> > 
> > Some chars are missing, as if a font could not be loaded. Also the
> > matrix of what is allowed and forbidden is not displayed at all for
> > any webpage I have tried. The bug looks similar to
> > 
> > webext-ublock-origin: Missing icons in the toolbar menu
> > https://bugs.debian.org/916431
> > 
> > where the issue was Firefox did not follow a relative symlink to the
> > necessary font file. Maybe something similar is the culprit here?
> 
> Hi Martin, symlinks is indeed the issue. Unfortunately and contrary to
> what was stated in that bug report, an absolute symlink doesn't work
> either.

Okay, thanks.

> For the time being you can work around the issue either by using
> firefox-esr instead of firefox (65) which is why I myself had not yet
> noticed this issue, it was working perfectly fine for me.

I'd rather use the latest stable Firefox that is available in unstable.

> If you cannot run firefox-esr and must run firefox 65, you can also
> work around the issue by running:
> 
> $ sudo rm /usr/share/webext/umatrix/lib/punycode.js
> $ sudo cp /usr/share/javascript/punycode/punycode.js
> /usr/share/webext/umatrix/lib/punycode.js

Thank you for the work-around. I did not yet come having another go with 
uMatrix, but I keep it in mind.

> Since it works perfectly fine in firefox-esr I assume it's a
> regression and that the firefox Debian maintainer can hopefully get a
> fix out soon.

It may be a new security feature in Firefox.

Well as I believe Debian stable will just have Firefox ESR – as Firefox 
without ESR would be difficult to provide security support for –  it is 
not important to have a fix in time for Buster.

Thanks,
-- 
Martin

Bug#921624: kmail: Crash during/after filtering inbox, probably related to Qt WebEngine integration

[Martin Steigerwald]

Hi.

Sandro Knauß - 03.03.19, 23:46:
[…]
> it does not looks like a packaging issue so far.

Sorry for not checking in with valgrind so far. I hope to take time for 
this this week.

> It may a duplicate of #923490.

Or other way around, my bug report was first :)

Thanks,
-- 
Martin