Bug#1002624: Screenshot attached

2021-12-25 Thread qazwsxedc


Bug#921771: Aw: Bug#921771: udev: hwdb --update no longer documented, but still required and working

2019-02-09 Thread qazwsxedc


Postscript: systemd-hwdb-update.service calls "systemd-hwdb update", which ignores any changes made in /etc/udev/hwdb.d/*.hwdb

It reverts any changes to hwdb.bin which have been made by "udevadm-hwdb --update"

Therefore the workaround command sequence required to ensure that changes made in /etc/udev/hwdb.d/*.hwdb are reflected in hwdb.bin *and persist* is:

 

systemctl mask systemd-hwdb-update.service

udevadm hwdb --update

udevadm trigger /dev/input/eventXX

 

Suggestion for a fix:

1. Deprecate systemd-hwdb

2. Modify udevadm help text and man page to show the "hwdb --update" command option again





Bug#842560: findutils: find fails to recurse from / downwards on first invocation after boot

2016-11-03 Thread qazwsxedc
[apologies, re-sending as plain text instead of html for the benefit of the bug 
tracker archive]

Had to build from source at 
http://ftp.gnu.org/gnu/findutils/findutils-4.6.0.tar.gz because version 
4.6.0+git+20160703-2 from the stretch repo won't install on jessie. The good 
news is that, yes, version 4.6.0 from the gnu repo did fix it.
 
Can I suggest that an installable flavour of 4.6.0 is made available in 
jessie-backports at least (jessie main would be even better)?
 
Regards,
Qaz
 

Gesendet: Sonntag, 30. Oktober 2016 um 13:00 Uhr
Von: "Andreas Metzler" <ametz...@bebt.de>
An: qazwsxedc <qazwsx...@gmx.net>, 842...@bugs.debian.org
Betreff: Re: Bug#842560: findutils: find fails to recurse from / downwards on 
first invocation after boot
On 2016-10-30 qazwsxedc <qazwsx...@gmx.net> wrote:
> Package: findutils
> Version: 4.4.2-9+b1
> Severity: important

> Dear Maintainer,

> find doesn't find on first invocation, only on second and subsequent ones 
> after
> a boot.
[...]

That looks pretty much identical to 
https://savannah.gnu.org/bugs/?47261[https://savannah.gnu.org/bugs/?47261]

Could you check whether it is also fixed with the latest release?

cu Andreas

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Bug#842560: findutils: find fails to recurse from / downwards on first invocation after boot

2016-11-03 Thread qazwsxedc

Had to build from source at http://ftp.gnu.org/gnu/findutils/findutils-4.6.0.tar.gz because version 4.6.0+git+20160703-2 from the stretch repo won't install on jessie. The good news is that, yes, version 4.6.0 from the gnu repo did fix it.

 

Can I suggest that an installable flavour of 4.6.0 is made available in jessie-backports at least (jessie main would be even better)?

 

Regards,

Qaz

 

Gesendet: Sonntag, 30. Oktober 2016 um 13:00 Uhr
Von: "Andreas Metzler" <ametz...@bebt.de>
An: qazwsxedc <qazwsx...@gmx.net>, 842...@bugs.debian.org
Betreff: Re: Bug#842560: findutils: find fails to recurse from / downwards on first invocation after boot

On 2016-10-30 qazwsxedc <qazwsx...@gmx.net> wrote:
> Package: findutils
> Version: 4.4.2-9+b1
> Severity: important

> Dear Maintainer,

> find doesn't find on first invocation, only on second and subsequent ones after
> a boot.
[...]

That looks pretty much identical to https://savannah.gnu.org/bugs/?47261

Could you check whether it is also fixed with the latest release?

cu Andreas

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'






Bug#842560: findutils: find fails to recurse from / downwards on first invocation after boot

2016-10-30 Thread qazwsxedc
Package: findutils
Version: 4.4.2-9+b1
Severity: important

Dear Maintainer,

find doesn't find on first invocation, only on second and subsequent ones after
a boot.

   * What led up to the situation?
Fresh boot, then log in as root.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Invoked the find command twice within seconds of each other. The first
invocation does not recurse down from the root of the file system except for
entering /sys/ The second and every subsequent invocation will recurse
properly. Example output:

root@host:~# find / -iname 'cpufrequtils*'
/sys/fs/cgroup/devices/system.slice/cpufrequtils.service
/sys/fs/cgroup/systemd/system.slice/cpufrequtils.service
root@host:~# find / -iname 'cpufrequtils*'
/sys/fs/cgroup/devices/system.slice/cpufrequtils.service
/sys/fs/cgroup/systemd/system.slice/cpufrequtils.service
/run/systemd/generator.late/runlevel5.target.wants/cpufrequtils.service
/run/systemd/generator.late/runlevel4.target.wants/cpufrequtils.service
/run/systemd/generator.late/runlevel3.target.wants/cpufrequtils.service
/run/systemd/generator.late/runlevel2.target.wants/cpufrequtils.service
/run/systemd/generator.late/cpufrequtils.service
/usr/share/lintian/overrides/cpufrequtils
/usr/share/doc/cpufrequtils
/usr/share/doc/cpufrequtils/examples/cpufrequtils.sample
/usr/share/doc/cpufrequtils/examples/cpufrequtils.loadcpufreq.sample
/usr/share/locale/pt/LC_MESSAGES/cpufrequtils.mo
/usr/share/locale/it/LC_MESSAGES/cpufrequtils.mo
/usr/share/locale/ca/LC_MESSAGES/cpufrequtils.mo
/usr/share/locale/fr/LC_MESSAGES/cpufrequtils.mo
/usr/share/locale/cs/LC_MESSAGES/cpufrequtils.mo
/usr/share/locale/de/LC_MESSAGES/cpufrequtils.mo
/etc/init.d/cpufrequtils
/var/lib/dpkg/info/cpufrequtils.prerm
/var/lib/dpkg/info/cpufrequtils.templates
/var/lib/dpkg/info/cpufrequtils.list
/var/lib/dpkg/info/cpufrequtils.conffiles
/var/lib/dpkg/info/cpufrequtils.postinst
/var/lib/dpkg/info/cpufrequtils.md5sums
/var/lib/dpkg/info/cpufrequtils.postrm

   * What was the outcome of this action?
First invocatoin of find did not actually find what it should find.

   * What outcome did you expect instead?
Output as shown by the second invocation (see above)




-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages findutils depends on:
ii  libc6  2.19-18+deb8u4

findutils recommends no packages.

Versions of packages findutils suggests:
ii  mlocate  0.26-1

-- no debconf information



Bug#825521: virtualbox: Virtualbox in full screen with pointer captured prevents screen lock on suspend

2016-05-27 Thread qazwsxedc
Package: virtualbox
Version: 5.0.18-dfsg-3~bpo8+1
Severity: normal

Dear Maintainer,

virtualbox 5.0.18 installed on Jessie with 4.5.0-0 kernel form backports, MATE
desktop 1.8.1

Suspending (to RAM) from MATE desktop using the lid switch of a laptop results
in a locked screen and a password prompt on wakeup, just as it should be.

Suspending (to RAM) while a virtualbox session is in full screen and has the
mouse pointer captured, again using the lid switch of a laptop, does NOT result
in a locked screen nor a password prompt on wakeup. Instead, the virtualbox
session is resumed, and it is then possible to move to another desktop of the
MATE environment by tapping the "host" key of Virtualbox (default is right
ctrl) followed by the shortcut combination to move to another desktop (default
ctrl-alt-right or ctrl-alt-left).

The outcome I expected instead was to be confronted with a MATE lock screen and
password prompt on resume.




-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox depends on:
ii  adduser   3.113+nmu3
ii  init-system-helpers   1.22
ii  libc6 2.19-18+deb8u4
ii  libcurl3-gnutls   7.38.0-4+deb8u3
ii  libgcc1   1:4.9.2-10
ii  libgsoap5 2.8.17-1
ii  libpng12-01.2.50-2+deb8u2
ii  libpython2.7  2.7.9-2
ii  libsdl1.2debian   1.2.15-10+b1
ii  libssl1.0.0   1.0.1k-3+deb8u4
ii  libstdc++64.9.2-10
ii  libvncserver0 0.9.9+dfsg2-6.1+deb8u1
ii  libvpx1   1.3.0-3
ii  libx11-6  2:1.6.2-3
ii  libxcursor1   1:1.1.14-1+b1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.1+dfsg1-5+deb8u1
ii  libxmu6   2:1.1.2-1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.9-9
ii  python2.7.9-1
ii  python2.7 2.7.9-2
pn  python:any
ii  virtualbox-dkms [virtualbox-modules]  5.0.18-dfsg-3~bpo8+1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  virtualbox-qt 5.0.18-dfsg-3~bpo8+1

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  5.0.16-1

-- no debconf information



Bug#823347: virtualbox-guest-additions-iso: Checks for updates without user consent or configurability

2016-05-03 Thread qazwsxedc
Package: virtualbox-guest-additions-iso
Version: 5.0.16-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
The Virtualbox guest additions appear to include functionality which "phones
home" and checks for updates being available, then notifies the user about them
if any are.

   * What exactly did you do (or not do) that was effective (or ineffective)?
Installed Virtualbox guest additions from virtualbox-guest-additions-iso into a
Debian Jessie VM on a Debian Jessie host

   * What was the outcome of this action?
See attached screenshot - a desktop notification pops up which tells the user
that an update is available.

   * What outcome did you expect instead?
No notification. I have this quaint notion that software should not "phone
home" without asking the user for permission and that there should be a
configurable option to suppress such behaviour, which defaults to "off".

This is concernnig because it implies that the software checks a central point
somewhere for existence of updates, leaking metadata about the user in the
process. It also increases the attack surface of the machine on which it runs.




-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

virtualbox-guest-additions-iso depends on no packages.

Versions of packages virtualbox-guest-additions-iso recommends:
ii  virtualbox  5.0.18-dfsg-3~bpo8+1

virtualbox-guest-additions-iso suggests no packages.

-- no debconf information


Bug#823343: virtualbox: User Manual refers to non-existent dialog

2016-05-03 Thread qazwsxedc
Package: virtualbox
Version: 5.0.18-dfsg-3~bpo8+1
Severity: normal

Dear Maintainer,

the virtualbox package installs /usr/share/doc/virtualbox/UserManual.pdf

On page 32, section 1.15, subsection 3 it lists an "Update" menu item which
does not exist in the Debian fork, presumably because it would pull in updates
from upstream and it would ignore Debian package management. This creates
confusion.

   * What led up to the situation?
I would guess that the user manual was only lightly edited before inclusion in
the package.

   * What exactly did you do (or not do) that was effective (or ineffective)?
I Read The Friendly Manual.

   * What was the outcome of this action?
I found a menu option listed which doesn't exist in the Debian fork, and for
good reason. This led me to go on a wild goose chase in relation to suppressing
update notifications for virtualbox-guest-additions (about which I'll raise a
seperate bug report).

   * What outcome did you expect instead?
To not find this menu option listed in the manual



-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox depends on:
ii  adduser   3.113+nmu3
ii  init-system-helpers   1.22
ii  libc6 2.19-18+deb8u4
ii  libcurl3-gnutls   7.38.0-4+deb8u3
ii  libgcc1   1:4.9.2-10
ii  libgsoap5 2.8.17-1
ii  libpng12-01.2.50-2+deb8u2
ii  libpython2.7  2.7.9-2
ii  libsdl1.2debian   1.2.15-10+b1
ii  libssl1.0.0   1.0.1k-3+deb8u4
ii  libstdc++64.9.2-10
ii  libvncserver0 0.9.9+dfsg2-6.1+deb8u1
ii  libvpx1   1.3.0-3
ii  libx11-6  2:1.6.2-3
ii  libxcursor1   1:1.1.14-1+b1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.1+dfsg1-5+deb8u1
ii  libxmu6   2:1.1.2-1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.9-9
ii  python2.7.9-1
ii  python2.7 2.7.9-2
pn  python:any
ii  virtualbox-dkms [virtualbox-modules]  5.0.18-dfsg-3~bpo8+1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  virtualbox-qt 5.0.18-dfsg-3~bpo8+1

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  5.0.16-1

-- no debconf information