Bug#1067469: script for generating the UI does not work

[Toni Mueller]

Hi Daniel,

On Fri, Mar 22, 2024 at 12:14:51PM +0100, Daniel Swarbrick wrote:
> The generate-ui.sh script was substantially refactored in June 2023. The

the patch only works for the script that ships with bookworm's 0.25
version. I have seen that the script has been completely re-done for
0.27, and it looks like that might work ootb.

> Can you try the script from the latest package from sid?
> 
> [1]: 
> https://salsa.debian.org/go-team/packages/prometheus-alertmanager/-/commits/debian/sid/debian/generate-ui.sh?ref_type=heads

Ok, I'll give it a try.


Thank you,
Toni

Bug#1050724: ignores fcitx 4

[Toni Mueller]

Package: terminator
Version: 2.1.2-2
Severity: normal
Tags: l10n upstream


Hi,

I have terminator installed, but can't for the life of me get fcitx to
activate. Hence, I am unable to write non-ascii characters in
Terminator.

The problem does seem to be fixed in terminator 2.1.3, where I can
activate fcitx so far. For me, this means that I need to use a "foreign" 
terminator for many things.


Thanks,
Toni


-- System Information:
Debian Release: trixie/sid
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages terminator depends on:
ii  gir1.2-glib-2.01.74.0-3
ii  gir1.2-gtk-3.0 3.24.37-2
ii  gir1.2-pango-1.0   1.50.14+ds-1
ii  gir1.2-vte-2.910.70.6-1
ii  gsettings-desktop-schemas  43.0-1
ii  python33.11.2-1+b1
ii  python3-cairo  1.20.1-5+b1
ii  python3-configobj  5.0.8-2
ii  python3-dbus   1.3.2-4+b1
ii  python3-gi 3.42.2-3+b1
ii  python3-gi-cairo   3.42.2-3+b1
ii  python3-psutil 5.9.4-1+b1

Versions of packages terminator recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.8-2~deb12u1
ii  dbus-x11 [dbus-session-bus]   1.14.8-2~deb12u1
ii  gir1.2-keybinder-3.0  0.3.2-1.1
ii  gir1.2-notify-0.7 0.8.2-1
ii  xdg-utils 1.1.3-4.1

terminator suggests no packages.

-- no debconf information

Bug#1036817: missing simplified version for 'sao' (187.8)

[Toni Mueller]

Package: fcitx-table
Version: 1:4.2.9.8-3
Severity: minor
Tags: upstream


Hi,

I am trying to write the character 'sao' (see attached image), but only
get the traditional version of it, which is then mistaken as a Japanese
character.

It would be nice if you could add this character.


Thanks,
Toni


-- System Information:
Debian Release: 11.7
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-22-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fcitx-table depends on:
ii  fcitx-bin  1:4.2.9.8-3
ii  fcitx-data 1:4.2.9.8-3
ii  fcitx-modules  1:4.2.9.8-3
ii  libc6  2.31-13+deb11u6

Versions of packages fcitx-table recommends:
ii  fcitx 1:4.2.9.8-3
ii  fcitx-pinyin  1:4.2.9.8-3

Versions of packages fcitx-table suggests:
ii  fcitx-table-all  1:4.2.9.8-3

-- no debconf information

Bug#1032857: please consider adding the jgrpp patches

[Toni Mueller]

Package: openttd
Version: 13.0-2
Severity: wishlist
Tags: upstream


Hi,

please consider packaging the jgrpp patches, too.

https://github.com/JGRennison/OpenTTD-patches

Thank you,
Toni



-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openttd depends on:
ii  libc62.31-13+deb11u5
pn  libfluidsynth3   
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s110.2.1-6
ii  libicu67 67.1-7
pn  libicu72 
ii  liblzma5 5.2.5-2.1~deb11u1
ii  liblzo2-22.10-2
ii  libpng16-16  1.6.37-3
ii  libsdl2-2.0-02.0.14+dfsg2-3+deb11u1
ii  libstdc++6   10.2.1-6
ii  libxdg-basedir1  1.2.0-2+b1
pn  openttd-data 
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages openttd recommends:
ii  openttd-opengfx  0.6.0-1
pn  openttd-openmsx  
pn  openttd-opensfx  
pn  timidity 

Versions of packages openttd suggests:
pn  openttd-opensfx  
pn  timidity 

Bug#1030356: signature verification issue CVE-2020-16156

[Toni Mueller]

Package: perl-base
Version: 5.32.1-4+deb11u2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 


Hi,

there's a signature verification problem with the CPAN module shipped
with bullseye. The problem seems to be fixed in CPAN 2.29.


Enjoy,
Toni



-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-20-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages perl-base depends on:
ii  dpkg   1.20.12
ii  libc6  2.31-13+deb11u5
ii  libcrypt1  1:4.4.18-4

perl-base recommends no packages.

Versions of packages perl-base suggests:
ii  perl5.32.1-4+deb11u2
ii  sensible-utils  0.0.14

-- no debconf information

Bug#1030355: heap overflow CVE-2022-3715

[Toni Mueller]

Package: bash
Version: 5.1-2+deb11u1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 



Hi,

according to RedHat, this bug was corrected in bash 5.1.8, but seems to
be usable to conduct at least a local DOS.


Enjoy,
Toni


-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-20-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bash depends on:
ii  base-files   11.1+deb11u6
ii  debianutils  4.11.2
ii  libc62.31-13+deb11u5
ii  libtinfo66.2+20201114-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-2

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#1024972: pip asks for a password, waits forever

[Toni Mueller]

Package: python3-pip
Version: 20.3.4-4+deb11u1
Severity: important
Tags: upstream



Hi,

there is this bug https://github.com/pypa/pip/issues/7883 that affects
Debian Bullseye. In a virtualenv, I have installed pip 22.3.1, which
does not have this flaw.

There is no action required for testing and later, but it would be nice
if this problem could be addressed in the next point release of
Bullseye.


Thanks,
Toni


-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-19-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pip depends on:
ii  ca-certificates 20210119
ii  python-pip-whl  20.3.4-4+deb11u1
ii  python3 3.9.2-3
ii  python3-distutils   3.9.2-1
ii  python3-setuptools  52.0.0-4
ii  python3-wheel   0.34.2-1

Versions of packages python3-pip recommends:
ii  build-essential  12.9
ii  python3-dev  3.9.2-3

python3-pip suggests no packages.

-- no debconf information

Bug#1020981: character missing from Chinese fonts and input methods

[Toni Mueller]

Package: task-chinese
Severity: normal


Hi,

I frequently find the character in the attached image somewhere, but
can't type it. In Wubi, the character code should probably be NWWI.

It would be great if you could add the character to fonts and input
methods.


Thanks,
Toni



-- System Information:
Debian Release: 11.5
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-18-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1006810: Workaround

[Toni Mueller]

Hi,

I just ran into the same problem.

First off, it's weird that apt fails to properly recognize that it needs
to upgrade wacom-common, but manually installing wacom-common did
upgrade this package, so that further upgrading was unblocked.


Enjoy,
Toni

Bug#1012615: Please provide PHP 8.1 as a backport

[Toni Mueller]

Package: php8.1
Severity: wishlist


Hi,

it would be great if PHP 8.1, and possibly other packages related to it,
like Symfony, were avialable as backports. ;)


Cheers,
Toni



-- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-14-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages php8.1 depends on:
pn  libapache2-mod-php8.1 | php8.1-fpm | php8.1-cgi  
pn  php8.1-common

php8.1 recommends no packages.

php8.1 suggests no packages.

Bug#1009615: forcibly starts chromium on several functions

[Toni Mueller]

Package: nextcloud-desktop
Version: 3.1.1-2+deb11u1
Severity: important
Tags: upstream


Hi,

I am running nextcloud-desktop in my .xsessionrc. When it starts, it
also fires up chromium, which I have installed, but which I rarely use.
Also, for a number of other activities, which were formerly part of the
nextcloud desktop client, it now also fires up chromium, although
chromium is not my standard browser. I have not found a way to make
nextcloud-client use my standard browser, which happens to be
firefox-esr, for such things, and I am also not prepared to run a second
browser in parallel just to interact with Nextcloud. In fact, I interact
with Nextcloud just fine using Firefox, and if these functions are only
available in the browser these days, they should imho be removed from
the menu. I can start a web browser myself, thank you very much!


Thanks,
Toni



-- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-13-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nextcloud-desktop depends on:
ii  libc6  2.31-13+deb11u3
ii  libcloudproviders0 0.3.0-3
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libnextcloudsync0  3.1.1-2+deb11u1
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5keychain10.10.0-1
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5qml5 5.15.2+dfsg-6
ii  libqt5quick5   5.15.2+dfsg-6
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5sql5-sqlite  5.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5webenginecore5   5.15.2+dfsg-3
ii  libqt5webenginewidgets55.15.2+dfsg-3
ii  libqt5webkit5  5.212.0~alpha4-11
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libstdc++6 10.2.1-6
ii  nextcloud-desktop-common   3.1.1-2+deb11u1
ii  nextcloud-desktop-l10n 3.1.1-2+deb11u1
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtqml-models2   5.15.2+dfsg-6
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-6
ii  qml-module-qtquick-window2 5.15.2+dfsg-6
ii  qml-module-qtquick25.15.2+dfsg-6

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.1.1-2+deb11u1

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#951831: Please update to 3.x

[Toni Mueller]

Hello,

I would also like to see groovy updated to the latest 3.x, because
several aspects of Jenkins pipelines do not work with Groovy 2.4, or at
least, not as documented.


Thanks,
Toni

Bug#993274: machine unbootable after upgrade

[Toni Mueller]

Hi Paul,

On Mon, Aug 30, 2021 at 10:10:12PM +0200, Paul Gevers wrote:
> On 29-08-2021 23:39, Toni Mueller wrote:
> > I am not sure why the upgrade process didn't handle this case, but think
> > the severity of the problem warrants a warning in the release notes.
> 
> Can you give a proposal for some text? After reading the old (closed)
> bug report, it's not clear to me what to warn for exactly as it seems
> that Colin there claims it's a broken configuration on your system.

the system was installed as a standard no-frills Buster system. I
haven't read why Colin thought that's a misconfiguration on the system,
but in my case, there has been no disk change, the system was installed
and then, sometime later, upgraded, which is when the problem occurred.

> Nobody brought it up to the release notes, so nothing was added.

Of course, I can only suggest something after seeing a problem. I would
suggest a text like this:


If your system is configured to boot from a RAID array, eg. MDADM, you
need to take extra precautions. After the upgrade procedure, but before
the reboot, you need to manually ensure that GRUB is properly installed
on all relevant disks. In the case of RAID1 (mirrored disks), do this:

 # lsblk
 sda...
 sdc...   # or sdb

You'll find the boot disks by their partitioning. For this example, it's
sda and sdc. Then run these commands:

 # grub-install /dev/sda
 # grub-install /dev/sdc



The other question is, why did this happen at all? I have previously
upgraded other systems with the same RAID configuration (ie, RAID1 via
mdadm), and can't remember having seen this problem. It would be better
to actually fix the problem, if possible.



Cheers,
Toni

Bug#993274: machine unbootable after upgrade

[Toni Mueller]

Package: upgrade-reports
Severity: grave


Hi,

I have recently upgraded a machine from Buster to Bullseye. The machine
runs on an mdadm RAID1. After the upgrade, it had the symptom outlined
in #931896.

I followed the upgrade process, as described in

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html


After completing this procedure, I ran

# apt install -f
# dpkg --configure -a

which both came up empty, suggesting that there was really no problem
left.


Since the machine didn't boot after upgrade, I'd say that warrants
'grave'.


As a fix, once I got access to the machine, running

# lsblk

to figure out the boot disks, then manually installing grub there like
this:


# grub-install /dev/sda
# grub-install /dev/otherdisk


solved the problem.


I am not sure why the upgrade process didn't handle this case, but think
the severity of the problem warrants a warning in the release notes.



Cheers,
Toni

Bug#980227: changed keyboard shortcuts ok

[Toni Mueller]

Hi,

I just noticed, but am in favour of this change. Makes it much harder to
close VM windows by accident, and also removes one collision point,
when the VM has windows which want Ctrl-W to be closed.


Thanks,
Toni

Bug#974939: closed by Ben Hutchings (Re: Bug#974939: machine does not boot)

[Toni Mueller]

Hi Ben,

On Mon, Nov 23, 2020 at 10:45:09AM +, Debian Bug Tracking System wrote:
> I recommend that you always check the list of packages to be removed in
> a dist-upgrade, if you have some packages installed from
> testing/unstable.

yes. :/

> It doesn't exist in stable.  Perhaps you installed something from
> testing/unstable that required it?  libgcc-s1 breaks the stable version
> of cryptsetup-initramfs.

I checked. My apt and libc6 are both from stable, and should thus only
have stable dependencies, right?

However, removing libgcc-s1 broke apt ("could not load shared
library...").


Thanks for the heads-ups,
Toni

Bug#974939: machine does not boot

[Toni Mueller]

Hi Ben,

On Mon, Nov 23, 2020 at 10:12:01AM +, Ben Hutchings wrote:
> On Mon, 2020-11-23 at 10:04 +0000, Toni Mueller wrote:
> > I agree, but I can only file a bug report against the kernel package.
> > Please find the output of this command attached.
> cryptsetup support is not included in the newer initramfs images.

I saw that, but was not aware of this package:

> Did you remove cryptsetup-initramfs by accident?

Not that I am aware of, and definitely not intentionally. Until now, I
had no idea that it even existed. But I can now see that it was removed
in a dist-upgrade run on the 9th of May last year (huh?!?). But there
seems to be a problem to re-install it:


# apt install cryptsetup-initramfs -y 

...

The following packages will be REMOVED:
  libgcc-s1
The following NEW packages will be installed:
  cryptsetup-initramfs
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  libgcc-s1
0 upgraded, 1 newly installed, 1 to remove and 2 not upgraded.
E: Essential packages were removed and -y was used without 
--allow-remove-essential.



Since libgcc-s1 is being provided by libgcc1, I am inclined to run with
--allow-remove-essential. But this is still quite scary!

(I wasn't aware of libgcc-s1, either. :(   )



Thanks,
Toni

Bug#974939: machine does not boot

[Toni Mueller]

Hi,

On Tue, Nov 17, 2020 at 12:50:19PM +0100, Bastian Blank wrote:
> On Mon, Nov 16, 2020 at 07:41:05PM +, Toni wrote:
> > Severity: critical
> 
> Sorry, no.  This problem does not break the package for everyone.
> 
> > On the console, after dmesg, these three lines repeat ad nauseum:
> > mdadm: No arrays found in config file or automatically
> >   Volume group "ev0" not found
> >   Cannot process volume group ev0
> > mdadm: No arrays found in config file or automatically
> >   Volume group "ev0" not found
> >   Cannot process volume group ev0
> 
> So it actually boots, but the boot process is not able to find your root
> filesystem?

It loads the kernel, I can see the dmesg, and then I see an endless loop
of these messages. So yes, there's something broken with encrypted
partitions, that wasn't broken until the -10 kernel.

> Yes, that look pretty normal and like something the Debian installer
> would create.

It did.

> What is the content of /etc/crypttab? /etc/fstab? /boot/grub/grub.conf?
> What do you have mdadm for?

I don't have mdadm devices in this machine (it's a laptop with only one
SSD, anyway). I don't know why mdadm is present on this machine, but it
has "always" been, with no detrimental effects until possibly recently.



Thanks,
Toni

Bug#962902: [debian-mysql] Bug#962902: server does not start

[Toni Mueller]

Hi Otto,

On Tue, Jun 16, 2020 at 12:27:53PM +0300, Otto Kekäläinen wrote:
> Can you provide us enough information about your environment so we
> could try to reproduce this error?

I'm not sure what you are after. The machine in question is a laptop
with Buster (latest), and all sorts of stiff.

I have other machines, also VMs (KVM), where this problem does not
occur. Eg. I have just 'apt dist-upgraded' a KVM VM on the same laptop,
which also has this software, and there, it just runs as expected. On
the host, which has very similar software, just much, much more, the
same thing fails. :(

My question is: Why does the server sometimes require this file to be
present, and where? I mean, this software has imho no business asking
for that file, to begin with.


Thanks,
Toni

Bug#946368: DeprecationWarning for using collections instead of collections.abc

[Toni Mueller]

Hi Thomas,

On Tue, Dec 10, 2019 at 08:47:02PM +0100, Thomas Goirand wrote:
> Do you feel like doing the work yourself for this? I have too many
> things to watch for stable updates...

I am strongly considering it if it's ok for you.


Cheers,
Toni

Bug#944022: Make Firehol Read The File

[Toni Mueller]

Hi Jerome,

On Sat, Nov 23, 2019 at 10:54:29AM +0400, Jerome BENOIT wrote:
> On 18/11/2019 21:39, Toni Mueller wrote:
> > My patch in Salsa may not yet be quite functional, but it changes the
> > 'firehol' script itself to read /etc/default/firehol and then exit if
> > this variable is not set to YES.
> 
> This sound as the best option.
> 
> Where is the patch (exactly) ?

I've just issued a MR, so you can see it properly. However, this MR does
not create a patch, but changes the script directly.

Enjoy!

Cheers,
Toni

Bug#944022: Make Firehol Read The File

[Toni Mueller]

Hi Jerome,

making the systemd unit file read /etc/default/firehol would not change
a thing because there is no logic available to act upon the
START_FIREHOL variable.

My patch in Salsa may not yet be quite functional, but it changes the
'firehol' script itself to read /etc/default/firehol and then exit if
this variable is not set to YES.


Cheers,
Toni

Bug#944022: suggested patch

[Toni Mueller]

Hi Michael,

forgot to say: Yes, it used to work in the past, but when firehol gained
a systemd service unit file, this functionality was lost. My patch
attempts to re-enable this functionality.


Cheers,
Toni

Bug#944078: [Pkg-utopia-maintainers] Bug#944078: firewall-applet: applet does not appear

[Toni Mueller]

Hi Michael,

On Sun, Nov 03, 2019 at 11:45:07PM +0100, Michael Biebl wrote:
> Am 03.11.19 um 23:28 schrieb Toni Mueller:
> > I have tried two versions that don't work. Switching window managers is
> > not an option for me, and generally, it should work everywhere (imho).
> > 
> > What would be the way forward?
> 
> If I had to guess I'd say it's either an issue of Qt5 or the tray
> application you are using in awesome. Might also be related to compositing.
> Maybe those hints help you further investigation this issue.

well, I have no clue about Qt, and I am using the standard awesome with
no special addons that I am aware of - just as it comes with buster,
plus a memory/cpu/battery widget. Every other program, like eg.
pavucontrol, screengrab, nm-applet, vlc, radiotray, redshift-gtk etc.,
has no problems adding itself to the tray. The systray is, to the best
of my very limited knowledge, a builtin feature of awesome. You have it
if you just install awesome.

Now what...


Cheers,
Toni

Bug#944078: firewall-applet: applet does not appear

[Toni Mueller]

Package: firewall-applet
Version: 0.7.2-1
Severity: important

Dear Maintainer,

I am trying to run the firewall-applet on my buster machine, and neither
the buster version nor the version in testing actually create the tray
applet. Instead, the program just hangs with no output. For the buster
version, I have stepped through the program to figure out where it
hangs:

$ python3 -m pdb /usr/bin/firewall-applet 
> /usr/bin/firewall-applet(23)()
-> import sys
(Pdb) n
> /usr/bin/firewall-applet(24)()
-> from PyQt5 import QtGui, QtCore, QtWidgets
(Pdb) 
> /usr/bin/firewall-applet(26)()
-> import gi
(Pdb) 
> /usr/bin/firewall-applet(27)()
-> gi.require_version('Notify', '0.7')
(Pdb) 
> /usr/bin/firewall-applet(28)()
-> from gi.repository import Notify
(Pdb) 
> /usr/bin/firewall-applet(30)()
-> import os
(Pdb) 
> /usr/bin/firewall-applet(31)()
-> from dbus.mainloop.pyqt5 import DBusQtMainLoop
(Pdb) 
> /usr/bin/firewall-applet(32)()
-> import functools
(Pdb) 
> /usr/bin/firewall-applet(34)()
-> from firewall import config
(Pdb) 
> /usr/bin/firewall-applet(35)()
-> from firewall.core.fw_nm import nm_is_imported, nm_get_zone_of_connection, \
(Pdb) 
> /usr/bin/firewall-applet(39)()
-> from firewall.core.watcher import Watcher
(Pdb) 
> /usr/bin/firewall-applet(40)()
-> from firewall.client import FirewallClient
(Pdb) 
> /usr/bin/firewall-applet(41)()
-> import slip.dbus
(Pdb) 
> /usr/bin/firewall-applet(42)()
-> import dbus
(Pdb) 
> /usr/bin/firewall-applet(43)()
-> import signal
(Pdb) 
> /usr/bin/firewall-applet(45)()
-> import gettext
(Pdb) 
> /usr/bin/firewall-applet(46)()
-> gettext.textdomain(config.DOMAIN)
(Pdb) 
> /usr/bin/firewall-applet(47)()
-> _ = gettext.gettext
(Pdb) 
> /usr/bin/firewall-applet(49)()
-> PATH = [ ]
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(51)()
-> if p not in PATH:
(Pdb) 
> /usr/bin/firewall-applet(52)()
-> PATH.append(p)
(Pdb) 
> /usr/bin/firewall-applet(50)()
-> for p in os.getenv("PATH").split(":"):
(Pdb) 
> /usr/bin/firewall-applet(54)()
-> def search_app(app):
(Pdb) 
> /usr/bin/firewall-applet(61)()
-> NM_CONNECTION_EDITOR = ""
(Pdb) 
> /usr/bin/firewall-applet(62)()
-> for binary in [ "/usr/bin/nm-connection-editor",
(Pdb) 
> /usr/bin/firewall-applet(68)()
-> if os.path.exists(binary):
(Pdb) 
> /usr/bin/firewall-applet(69)()
-> NM_CONNECTION_EDITOR = binary
(Pdb) 
> /usr/bin/firewall-applet(70)()
-> break
(Pdb) 
> /usr/bin/firewall-applet(72)()
-> PY2 = sys.version < '3'
(Pdb) 
> /usr/bin/firewall-applet(74)()
-> def escape(text):
(Pdb) 
> /usr/bin/firewall-applet(80)()
-> def fromUTF8(text):
(Pdb) 
> /usr/bin/firewall-applet(87)()
-> class ZoneInterfaceEditor(QtWidgets.QDialog):
(Pdb) 
> /usr/bin/firewall-applet(160)()
-> class ZoneConnectionEditor(ZoneInterfaceEditor):
(Pdb) 
> /usr/bin/firewall-applet(185)()
-> class ZoneSourceEditor(ZoneInterfaceEditor):
(Pdb) 
> /usr/bin/firewall-applet(201)()
-> class 

Bug#944022: firehol: default config is unusable for a server

[Toni Mueller]

Package: firehol
Version: 3.1.6+ds-8
Severity: important

Dear Maintainer,

as-is, the firehol package installs a set of filters that will disable
access to the server. This would not be a problem if the package would
not also immediately start firehol, ie, implement this configuration. I
found that it shouldn't be started, but it definitely is, despite
/etc/defaults/firehol saying "START_FIREHOL=NO".

The effect is that if you install this package on a server, you're
immediately losing contact and have no remedy to fix that.

Suggested fix: Do not enable this service during installation, at least
not on a server, or install a default policy like this:

interface any world
policy accept


Cheers,
Toni


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (550, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firehol depends on:
ii  firehol-common  3.1.6+ds-8
ii  lsb-base10.2019051400

Versions of packages firehol recommends:
ii  fireqos  3.1.6+ds-8

Versions of packages firehol suggests:
pn  firehol-doc
pn  firehol-tools  
pn  ulogd2 

-- Configuration Files:
/etc/firehol/firehol.conf changed [not included]

-- no debconf information

Bug#932922: repo links should be taken from latest upload, not old versions

[Toni Mueller]

Hi Boyuan,

On Wed, Jul 24, 2019 at 03:31:33PM -0400, Boyuan Yang wrote:
> While what you said is reasonable, where is the latest upload of
> virtualenvwrapper? It seems that the package received no upload since 2014.

good question. I had to hunt a little myself, and came up with this:

https://bitbucket.org/virtualenvwrapper/virtualenvwrapper/src/master/

On PyPI, they mention a package version of 4.8.4, which is also
mentioned on the tracker page, but in Debian, the latest version is
4.3.1.

Thanks for spotting this!


Cheers,
Toni

Bug#928894: [pkg-gnupg-maint] Bug#928894: custom keyring is not honoured

[Toni Mueller]

Hi Daniel,

On Sun, May 12, 2019 at 06:52:17PM -0400, Daniel Kahn Gillmor wrote:
> I'm not sure that this demonstrates what you're describing.
> 
> Here is a run with gpg 2.2.15-1 that demonstrates the key being fetched
> into the extra keyring:
> 
> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ export GNUPGHOME=$(pwd)

I did not do this. This variable is unset in my environment.

> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ touch $(pwd)/extra.gpg
> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ gpg --no-default-keyring --keyring 
> $(pwd)/extra.gpg --recv-keys CC64B1DB67ABBEECAB24B6455FC346329753F4B0
> gpg: key 2D9AE806EC1592E2: 6 signatures not checked due to missing keys
> gpg: /tmp/cdtemp.AhkyjS/trustdb.gpg: trustdb created
> gpg: key 2D9AE806EC1592E2: public key "Teabot " imported
> gpg: no ultimately trusted keys found
> gpg: Total number processed: 1
> gpg:   imported: 1
> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ gpg --list-options show-keyring -k 
> tea...@gitea.io
> gpg: keybox '/tmp/cdtemp.AhkyjS/pubring.kbx' created
> gpg: error reading key: No public key
> 2 dkg@alice:/tmp/cdtemp.AhkyjS$ ls -la
> total 24
> drwx--  4 dkg  dkg   160 May 12 18:48 .
> drwxrwxrwt 28 root root 1420 May 12 18:47 ..
> drwx--  2 dkg  dkg60 May 12 18:48 crls.d
> -rw-r--r--  1 dkg  dkg  6467 May 12 18:48 extra.gpg
> -rw-r--r--  1 dkg  dkg  6467 May 12 18:48 extra.gpg~
> drwx--  2 dkg  dkg40 May 12 18:48 private-keys-v1.d
> -rw---  1 dkg  dkg32 May 12 18:48 pubring.kbx
> -rw---  1 dkg  dkg  1200 May 12 18:48 trustdb.gpg
> 0 dkg@alice:/tmp/cdtemp.AhkyjS$ 

Your experiment only shows that the key did *not* end
up in /tmp/cdtemp.AhkyjS/pubring.kbx. Otherwise, the "gpg -k" above
should have listed it, instead of saying "No public key".

> perhaps the teabot key was already in your default keyring before you
> run the --recv-keys operation?  that would certainly explain the
> behavior that you're seeing.

No, it does not. If a key is already there, it would not say
"imported: 1". And since it said "imported: 1" for you, I challenge you
to find the location of that key, because it is obviously not in your
temporary keyring.

For what it's worth, here's another run, setting GNUPGHOME:


$ touch ~/mnt/tools/gitea-keys.gpg
$ GNUPGHOME=`/bin/pwd`
$ echo ${GNUPGHOME}
/home/toni/mnt/tools
$ gpg --list-options show-keyring -k tea...@gitea.io
gpg: please do a --check-trustdb
gpg: error reading key: No public key
$ gpg  --keyring ~/mnt/tools/gitea-keys.gpg   --list-options show-keyring -k 
tea...@gitea.io
gpg: please do a --check-trustdb
gpg: error reading key: No public key
$ gpg  --keyring ~/mnt/tools/gitea-keys.gpg --no-default-keyring --recv-keys 
CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: key 0x2D9AE806EC1592E2: 6 signatures not checked due to missing keys
gpg: key 0x2D9AE806EC1592E2: public key "Teabot " imported
gpg: Total number processed: 1
gpg:   imported: 1
$ gpg  --keyring ~/mnt/tools/gitea-keys.gpg --no-default-keyring --recv-keys 
CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: key 0x2D9AE806EC1592E2: 6 signatures not checked due to missing keys
gpg: key 0x2D9AE806EC1592E2: "Teabot " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
$ gpg  --keyring ~/mnt/tools/gitea-keys.gpg   --list-options show-keyring -k 
tea...@gitea.io
gpg: please do a --check-trustdb
Keyring: /home/toni/.gnupg/pubring.gpg
--
pub   rsa4096/0x2D9AE806EC1592E2 2018-06-24 [SC] [expires: 2020-06-23]
  7C9E68152594688862D62AF62D9AE806EC1592E2
uid   [ unknown] Teabot 
sub   rsa4096/0x1FBE01D7CBADB9A0 2018-06-24 [E] [expires: 2020-06-23]
sub   rsa4096/0x5FC346329753F4B0 2018-06-24 [S] [expires: 2019-06-24]

$ l `/bin/pwd`/gitea-keys.gpg
-rw-r- 1 toni toni 0 May 13 00:55 /home/toni/mnt/tools/gitea-keys.gpg
$ 


Enjoy,
Toni

Bug#923082: can't disable systemd-resolved

[Toni Mueller]

Hi Martin,

On Sun, Feb 24, 2019 at 08:03:38AM +0100, Martin Pitt wrote:
> Toni [2019-02-23 23:05 +]:
> > I can't disable systemd-resolved, which prevents me from running my own
> > DNS setup:
> 
> systemd-resolved.service is not enabled by default in Debian. If you enabled
> it, what prevents you from disabling it again? (systemctl disable
> systemd-resolved).

I really can't remember having enabled it - and I also don't know why I
would have done it, having my own setup in several of the areas that
systemd is encroaching on. But what prevents me from disabling systemd,
is quite simple: It just does not work:


# systemctl stop systemd-resolved
# lsof -i udp@0.0.0.0:53
COMMAND   PID   USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
systemd 1   root  113u  IPv4   10583  0t0  UDP localhost:domain


That's why I filed a bug report - it really should be possible to
disable this service.

> resolved doesn't run in pid 1 (that would be a really bad architecture!). This
> just means that pid 1 connected to localhost's name server to resolve a name
> (i. e. a DNS client). A better command to find out which processes are
> *listening* on UDP ports is "ss -ulpen", or for port 53 specifically,
> "ss -ulpen 'sport = 53'".

# ss -ulpen 'sport = 53'
State Recv-QSend-Q   Local Address:Port 
Peer Address:Port
UNCONN0 0192.168.122.1:53   
 0.0.0.0:*users:(("dnsmasq",pid=13861,fd=5)) ino:5159825 
sk:a1 <->
UNCONN0 0127.0.0.1:53   
 0.0.0.0:*users:(("systemd",pid=1,fd=113)) ino:10583 sk:a2 
<->
UNCONN0 0[::1]:53   
[::]:*users:(("systemd",pid=1,fd=111)) ino:362 sk:a3 
v6only:1 <->

This I took after trying to stop systemd-resolved.

Other things I tried:

 * setting DNSStubListener=no in /etc/systemd/resovled.conf, followed by
 * systemctl daemon-reload, followed by
 * systemctl daemon-reexec

But it was all for naught.


Kind regards,
Toni

Bug#921387: UI on HIDPI too small

[Toni Mueller]

On Sat, Feb 09, 2019 at 04:37:17PM +0100, Rene Engelhard wrote:
> And then there's the GNOME/Gtk3/Qt/... settings.

If these accessibility features would be tunable by environment
variables which were interpreted by libraries or config files, that
would be perfectly fine by me. If I could just install some libraries or
such a settings program and then set those values in a way that I would
have them in awesome, but without Gome and friends, that would also be
perfectly acceptable.

> You have choosen awesome.

And for a good reason. For about everything else in those "desktop
environments" does not work for me and my workflows. I've lost my
desktop environments more often than I can remember, due to profile
corruption on every computer and every version I tried, to the point
that I could not even run Firefox on a pretty vanilla Gnome in Stretch,
where I once arrived in a situation where deleting all dot files and
directories under ~user/ did not make it work again. However, shutting
down Gnome and starting awesome fixed the problem immediately.

This accessibility issue does not outweigh the plethora of problems I
experience with "desktop enviromnents" within weeks or days after trying
to use them, and should imho be solved in a generic way that's open to
every GUI user.


Cheers,
Toni

Bug#921387: UI on HIDPI too small

[Toni Mueller]

Hi Rene,

On Sat, Feb 09, 2019 at 11:03:21AM +0100, Rene Engelhard wrote:
> Neither do I, but do you really attempt to use 3840x2160 and are suprised 
> this is small on
> a 15"?

I don't "really attempt", it just automatically configured itself this
way. And I actually welcome the smoother characters.

Yes, I am "surprised" this is small, because that's imho the only reason
why software would claim abilities to work on HIDPI displays - that it
can automatically detect and adapt to different DPI figures to give a
similar experience everywhere. That's also the only reason why we
measure font sizes in points instead of pixels. Not honouring the screen
resolution would imho make a claim to HIDPI compatibility invalid.

The only thing I can really see failing here, is that the output of
xrandr shows 96x96 dpi, which is patently untrue. If I knew where to
look, I would want to fix that (xorg driver? xorg base? elsewhere?).

If there was a way to adjust the UI font sizes, that could be a useful
band aid, but I largely unaware of such a thing.


Cheers,
Toni

Bug#921387: UI on HIDPI too small

[Toni Mueller]

Hi Rene,

On Fri, Feb 08, 2019 at 07:41:58PM +0100, Rene Engelhard wrote:
> screen #0:
>   dimensions:1920x1080 pixels (290x170 millimeters)
>   resolution:168x161 dots per inch
>   depths (7):24, 1, 4, 8, 15, 16, 32
>   root window id:0x39c
>   depth of root window:24 planes
>   number of colormaps:minimum 1, maximum 1
>   default colormap:0x23
>   default number of colormap cells:256
>   preallocated pixels:black 0, white 16777215
>   options:backing-store WHEN MAPPED, save-unders NO
>   largest cursor:1920x1080

$ xrandr --verbose
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 8192 x 8192
eDP-1 connected primary 3840x2160+0+0 (0x67) normal (normal left inverted right 
x axis y axis) 344mm x 194mm
Identifier: 0x62
Timestamp:  90357
Subpixel:   unknown
Gamma:  1.0:1.3:1.7
Brightness: 0.55
Clones:
CRTC:   0
CRTCs:  0 1 2
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID: 
00004d108d14
051c0104a52213780ead27a95335bc25
0c51540001010101010101010101
0101010101014dd000a0f0703e803020
350058c21018
00fe0046
4e564452804c513135364431
000241032801120b010a202000b6
scaling mode: Full aspect 
supported: Full, Center, Full aspect
Broadcast RGB: Automatic 
supported: Automatic, Full, Limited 16:235
link-status: Good 
supported: Good, Bad
CONNECTOR_ID: 71 
supported: 71
non-desktop: 0 
range: (0, 1)


(I don't understand everything in there...)


> Does export SAL_USE_VCLPLUGIN=gtk3 (install libreoffice-gtk3...) change it? 
> That would
> use the "gtk3" plugin. (As done automatically when LO detects it runs under 
> GNOME)

Yes, texts are now a little larger - but in the UI not very much.


Cheers,
Toni

Bug#921387: UI on HIDPI too small

[Toni Mueller]

Hi Rene,

On Wed, Feb 06, 2019 at 08:12:48PM +0100, Rene Engelhard wrote:
> On Mon, Feb 04, 2019 at 10:37:38PM +, Toni wrote:
> > on my HIDPI display, most UI elements, and especially the file dialogue,
> > are too small. I tried setting environment variables, as suggested in
> > the Arch wiki, but to no avail (I tried both GTK3 and QT settings).
> 
> This is pretty subjective, isn't it?

yes, but if things turn out to be maybe 6pt on a "normal" screen, as a
rough estimate, I think it is safe to say that this is too small. That'd
be too small for latin characters only, but I also have a significant
number of more complex chacaters (mostly Chinese), which are absolutely
unreadable at that size.

> At leat in my GNOME here on my new laptop this is quite small on
> 1920x1080 but not unbearable even with my eyes..

I have a 15" laptop and 294 dpi. But I noticed something else, that the
resolution is set to 96x96, according to the X11 log file. Maybe there's
a bug in the graphics driver, not in the application.

> Your scenario is something no-GTk3 and no KDE integration?

Maybe. I use plain awesome, which I start with "startx" from a text
console.


Kind regards,
Toni

Bug#920547: Crashes every few hours

[Toni Mueller]

Hi Ben,

On Mon, Jan 28, 2019 at 12:42:37AM +, Ben Hutchings wrote:
> On Sat, 26 Jan 2019 20:03:49 + Toni  wrote:
> > Package: src:linux
> > Version: 4.19.16-1
> > Severity: critical
> > File: linux-image-4.19.0-2-amd64
> 
> Is this a new problem with version 4.19.16-1?  Or did it happen with
> earlier versions as well?

it happened with the 4.18.* kernel as well. The machine came with Ubuntu
and 4.13 preinstalled, but I wiped it as soon as I could and installed
Debian. So I don't know if it would have worked with Ubuntu - the entire
setup was not suitable for my purposes, but I thought that 4.9 might be
too old for this hardware.

However, the machine came with a 1.3 BIOS, which I updated to 1.6 and
then to 1.7. I think, I had 4.18 together with 1.6 running, but closed
the corresponding bug report when I noticed that both a newer kernel and
a newer BIOS were available. Well, the situation compared has improved a
little, compared to that, but it is still very bad.

> When you say "data loss", are you talking about data in memory or
> corruption of files that were saved and sync'd to disk?

I mean, files on disk were destroyed. I noticed some because I use
etckeeper with git, and suddenly, I could no longer see my update
history because files in /etc/.git were corrupt to the point that no
"git fsck" or "git gc" could resurrect the tree.

> On x86 laptops thermal management is (by default) done by the system
> firmware (BIOS and management engine code).  If you didn't override
> that, and yet the CPU overheats, this is the manufacturer's fault.

Ok... In the BIOS, I set the corresponding parameter from "performance"
to "normal", which I hoped would be a more conservative setting, to
prevent exactly this problem.


Cheers,
Toni

Bug#842015: one more data point

[Toni Mueller]

Hi,

I am not a Gnome user, but somehow had this package installed on machine
A. I was logged in on machine A, but had a screen lock on.  On machine
B, I was also logged in, running something like "ssh -XCA machineA"
where I tried to "gbp buildpackage". This got stuck at the signing
phase, with no output on my terminal (ie, in the SSH session). If I
typed something, I had local echo. I could kill the program by typing
Ctrl-C.

Both machines are running the latest Stretch/amd64.


Thanks,
Toni

Bug#892275: Problem exists in Buster

[Toni Mueller]

Hi,

I can say that the problem exists in version 1.11-2. On my system, the
output from the systemctl command is as follows:

$ systemctl --user status redshift
● redshift.service - Redshift display colour temperature adjustment
   Loaded: loaded (/usr/lib/systemd/user/redshift.service; enabled; vendor 
preset: enabled)
   Active: inactive (dead)
 Docs: http://jonls.dk/redshift/


I tried to start the process by hand, and it sort of worked. But
redshift still hangs with the message that it is trying to figure
out the location using geoclue2.


Cheers,
Toni

Bug#901930: [pkg-wicd-maint] Bug#901930: crash upon trying to enter "Config"

[Toni Mueller]

Hi Axel,

On Wed, Jun 20, 2018 at 02:06:41PM +0200, Axel Beckert wrote:
> On a first glance it looks as if this issue only happens if a specific
> flow path is taken in wicd-curses. It would be interesting to know
> under which circumstances it exactly happens for you.
> 
> I assume it's reproducible for you.

yes, it is: On a buster machine, installed yesterday and today, I can do
the following:

* as root, start wicd-curses.
* press the right arrow key
* crash!


Cheers,
Toni

Bug#901930: crash upon trying to enter "Config"

[Toni Mueller]

Package: wicd-curses
Version: 1.7.4+tb2-6
Severity: important
Tags: upstream


Hi,

I am trying to run wicd-curses, but it crashes hard. I've culled the
control characters and the boilerplate ("About" etc.) from the
typescript:


root@nutshell:~# wicd-curses
... Not connected ...

Traceback (most recent call last):
  File "/usr/share/wicd/curses/wicd-curses.py", line 1149, in call_update_ui
self.update_ui(True)
  File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper
return func(*args, **kargs)
  File "/usr/share/wicd/curses/wicd-curses.py", line 1162, in update_ui
self.handle_keys(input_data)
  File "/usr/share/wicd/curses/wicd-curses.py", line 1040, in handle_keys
self.diag = WirelessSettingsDialog(pos, self.frame)
  File "/usr/share/wicd/curses/netentry_curses.py", line 503, in __init__
self.set_values()
  File "/usr/share/wicd/curses/netentry_curses.py", line 539, in set_values
self.bitrates.append('auto')
AttributeError: 'dbus.String' object has no attribute 'append'



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: Apparmor: enabled

Versions of packages wicd-curses depends on:
ii  python2.7.15-3
ii  python-urwid  2.0.1-2
ii  wicd-daemon   1.7.4+tb2-6

Versions of packages wicd-curses recommends:
ii  sudo  1.8.2301

wicd-curses suggests no packages.

Versions of packages wicd-daemon depends on:
ii  adduser  3.117
ii  dbus 1.12.8-2
ii  debconf  1.5.67
ii  iputils-ping 3:20161105-1
ii  isc-dhcp-client  4.3.5-4
ii  lsb-base 9.20170808
ii  psmisc   23.1-1+b1
ii  python   2.7.15-3
ii  python-dbus  1.2.8-2
ii  python-gobject-2 2.28.6-13+b1
ii  python-wicd  1.7.4+tb2-6
ii  wireless-tools   30~pre9-12+b1
ii  wpasupplicant2:2.6-16

Versions of packages wicd-daemon recommends:
ii  rfkill  0.5-1+b1

Versions of packages wicd-daemon suggests:
ii  pm-utils  1.4.1-17

Versions of packages python-wicd depends on:
ii  python  2.7.13-2

-- debconf information excluded

Bug#901448: search generates broken URL

[Toni Mueller]

Package: python-flask-doc
Version: 1.0.2-1
Severity: normal


Hi,

when I conduct a search, at least some of the results are wrong.

Eg. searching for "session" yields a list, which contains this link:

http://localhost/Flask/api.rst.html?highlight=session#flask.session

Please note the ".rst" part in there. If I strip this out, the resulting
URL works just fine:

http://localhost/Flask/api.html?highlight=session#flask.session

It would be nice if the search could generate proper links in the first
place.


Cheers,
--Toni++


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-flask-doc depends on:
ii  libjs-sphinxdoc  1.4.9-2

Versions of packages python-flask-doc recommends:
ii  python-flask  0.12.1-1

python-flask-doc suggests no packages.

-- no debconf information

Bug#898718: pressing the 'Escape' key while editing a title causes terminator to exit

[Toni Mueller]

Package: terminator
Version: 1.90+bzr-1705-1
Severity: normal


Hi!

I am using terminator under awesome (no Gnome or so), and frequently
inadvertantly end up having my mouse on the title bar with the option to
edit the window title. In such a situation, the title bar appears to be
a litte bit enlarged, and there is a text input window with a white
background, and the existing text in this input field, provided by the
original window title, appears to be selected (white on blue). When I
just want to exit this dialogue in the way I exist most dialogues, by
pressing the Escape key, the entire terminal vanishes, together with all
other tabs and shells inside.

I find this pretty annoying, but have no real idea on how to fix it,
except for changing my behaviour.

But I would like the terminal program to at least ask for confirmation
before killing all my even unrelated shells.

If you want to reproduce the bug, just open terminator, then double
click on the window title, then press Escape.


Cheers,
Toni


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages terminator depends on:
ii  gir1.2-glib-2.0   1.50.0-1+b1
ii  gir1.2-gtk-3.03.22.11-1
ii  gir1.2-pango-1.0  1.40.5-1
ii  gir1.2-vte-2.91   0.46.1-1
ii  python2.7.13-2
ii  python-cairo  1.8.8-2.2
ii  python-dbus   1.2.4-1+b1
ii  python-gi 3.22.0-2
ii  python-gi-cairo   3.22.0-2
ii  python-psutil 5.0.1-1

Versions of packages terminator recommends:
ii  gir1.2-keybinder-3.0  0.3.1-1
ii  gir1.2-notify-0.7 0.7.7-2
ii  xdg-utils 1.1.1-1

terminator suggests no packages.

-- no debconf information

Bug#815037: problem still present in Stretch and stretch-backports?

[Toni Mueller]

Hi,

I am seeing this problem with

linux-image-4.15.0-0.bpo.2-amd64 4.15.11-1~bpo9+1 amd64 and firmware-iwlwifi 
20170823-1~bpo9+1, and with their counterparts from Stable on my
XPS 13 from around 2013.

FWIW, on some networks, I have no trouble connecting, but on others, it just
won't work at all. I've tried this backport version after losing
connectivity with the stable package.



$ journalctl -b 0 | grep iwlwifi | head
Apr 30 23:27:08 debian kernel: iwlwifi :01:00.0: can't disable ASPM; OS 
doesn't have ASPM control
Apr 30 23:27:08 debian kernel: iwlwifi :01:00.0: firmware: direct-loading 
firmware iwlwifi-6000g2b-6.ucode
Apr 30 23:27:08 debian kernel: iwlwifi :01:00.0: loaded firmware version 
18.168.6.1 op_mode iwldvm
Apr 30 23:27:08 debian kernel: iwlwifi :01:00.0: CONFIG_IWLWIFI_DEBUG 
disabled
Apr 30 23:27:08 debian kernel: iwlwifi :01:00.0: CONFIG_IWLWIFI_DEBUGFS 
disabled
Apr 30 23:27:08 debian kernel: iwlwifi :01:00.0: 
CONFIG_IWLWIFI_DEVICE_TRACING disabled
Apr 30 23:27:08 debian kernel: iwlwifi :01:00.0: Detected Intel(R) 
Centrino(R) Advanced-N 6235 AGN, REV=0xB0
Apr 30 23:27:09 debian kernel: iwlwifi :01:00.0: Radio type=0x2-0x1-0x0
Apr 30 23:27:09 debian kernel: iwlwifi :01:00.0: Radio type=0x2-0x1-0x0
Apr 30 23:27:38 debian kernel: iwlwifi :01:00.0: Radio type=0x2-0x1-0x0


$ iwconfig wlan0   
wlan0 IEEE 802.11  ESSID:off/any  
  Mode:Managed  Frequency:5.22 GHz  Access Point: Not-Associated   
  Tx-Power=15 dBm   
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Power Management:off




Here's one such section from the logs, I get them every few seconds:


Apr 30 23:43:30 debian kernel: [  995.983609] ieee80211 phy0: Hardware restart 
was requested
Apr 30 23:43:30 debian kernel: [  995.996648] iwlwifi :01:00.0: Radio 
type=0x2-0x1-0x0
Apr 30 23:43:30 debian kernel: [  996.297641] iwlwifi :01:00.0: Radio 
type=0x2-0x1-0x0
Apr 30 23:43:38 debian kernel: [ 1003.669572] iwlwifi :01:00.0: Microcode 
SW error detected.  Restarting 0x200.
Apr 30 23:43:38 debian kernel: [ 1003.669589] iwlwifi :01:00.0: Loaded 
firmware version: 18.168.6.1
Apr 30 23:43:38 debian kernel: [ 1003.669781] iwlwifi :01:00.0: Start IWL 
Error Log Dump:
Apr 30 23:43:38 debian kernel: [ 1003.669789] iwlwifi :01:00.0: Status: 
0x004C, count: 6
Apr 30 23:43:38 debian kernel: [ 1003.669797] iwlwifi :01:00.0: 0x0034 
| NMI_INTERRUPT_WDG   
Apr 30 23:43:38 debian kernel: [ 1003.669803] iwlwifi :01:00.0: 0x00010564 
| uPc
Apr 30 23:43:38 debian kernel: [ 1003.669810] iwlwifi :01:00.0: 0x0001054E 
| branchlink1
Apr 30 23:43:38 debian kernel: [ 1003.669816] iwlwifi :01:00.0: 0x00010580 
| branchlink2
Apr 30 23:43:38 debian kernel: [ 1003.669824] iwlwifi :01:00.0: 0xDBEA 
| interruptlink1
Apr 30 23:43:38 debian kernel: [ 1003.669831] iwlwifi :01:00.0: 0x0001CB38 
| interruptlink2
Apr 30 23:43:38 debian kernel: [ 1003.669837] iwlwifi :01:00.0: 0x0002 
| data1
Apr 30 23:43:38 debian kernel: [ 1003.669844] iwlwifi :01:00.0: 0x0703 
| data2
Apr 30 23:43:38 debian kernel: [ 1003.669851] iwlwifi :01:00.0: 0x0002617C 
| line
Apr 30 23:43:38 debian kernel: [ 1003.669858] iwlwifi :01:00.0: 0x11C0121E 
| beacon time
Apr 30 23:43:38 debian kernel: [ 1003.669865] iwlwifi :01:00.0: 0x9B5B2DE2 
| tsf low
Apr 30 23:43:38 debian kernel: [ 1003.669871] iwlwifi :01:00.0: 0x0055 
| tsf hi
Apr 30 23:43:38 debian kernel: [ 1003.669876] iwlwifi :01:00.0: 0x 
| time gp1
Apr 30 23:43:38 debian kernel: [ 1003.669882] iwlwifi :01:00.0: 0x0070585B 
| time gp2
Apr 30 23:43:38 debian kernel: [ 1003.669889] iwlwifi :01:00.0: 0x 
| time gp3
Apr 30 23:43:38 debian kernel: [ 1003.669896] iwlwifi :01:00.0: 0x754312A8 
| uCode version
Apr 30 23:43:38 debian kernel: [ 1003.669905] iwlwifi :01:00.0: 0x00B0 
| hw version
Apr 30 23:43:38 debian kernel: [ 1003.669911] iwlwifi :01:00.0: 0x00484B00 
| board version
Apr 30 23:43:38 debian kernel: [ 1003.669918] iwlwifi :01:00.0: 0x0207001C 
| hcmd
Apr 30 23:43:38 debian kernel: [ 1003.669924] iwlwifi :01:00.0: 0xA7863002 
| isr0
Apr 30 23:43:38 debian kernel: [ 1003.669930] iwlwifi :01:00.0: 0x11898000 
| isr1
Apr 30 23:43:38 debian kernel: [ 1003.669935] iwlwifi :01:00.0: 0x0E17 
| isr2
Apr 30 23:43:38 debian kernel: [ 1003.669941] iwlwifi :01:00.0: 0x8543FCC0 
| isr3
Apr 30 23:43:38 debian kernel: [ 1003.669947] iwlwifi :01:00.0: 0x 
| isr4
Apr 30 23:43:38 debian kernel: [ 1003.669954] iwlwifi :01:00.0: 0x00804110 
| isr_pref
Apr 30 23:43:38 debian kernel: [ 1003.669961] iwlwifi :01:00.0: 0x0002617C 
| wait_event
Apr 30 23:43:38 debian kernel: [ 1003.669969] iwlwifi :01:00.0: 0x00B4 
| l2p_control
Apr 30 23:43:38 debian kernel: [ 1003.669976] iwlwifi :01:00.0: 0x00A4 
| l2p_duration
Apr 30 23:43:38 debian 

Bug#892955: [Pkg-mongodb-maintainers] Bug#892955: mongodb-server: enabling the 'oplog' config option makes server fail to start

[Toni Mueller]

Hi Apollon,

On Thu, Mar 15, 2018 at 09:38:17AM +0200, Apollon Oikonomopoulos wrote:
> Indeed, it appears the option has been called "diaglog" for the past 9 
> years, can you give it a try? We need to update the package's default 
> config I guess...

;}

I changed the config to say "diaglog=7", and the server starts with
that.


Cheers,
Toni

Bug#892955: mongodb-server: enabling the 'oplog' config option makes server fail to start

[Toni Mueller]

Package: mongodb-server
Version: 1:3.2.11-2+deb9u1
Severity: normal


Hi,

I just installed mongodb and wanted to get more detailed logging, so I
removed the comment from 'oplog = 0' and switched to 7:

# Set oplogging level where n is
#   0=off (default)
#   1=W
#   2=R
#   3=both
#   7=W+some reads
oplog = 7


After that, the server refused to start, and I found this in the log:

... mongod[385]: Error parsing INI config file: unrecognised option 'oplog'


Cheers,
--Toni++


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (90, 'testing'), (70, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mongodb-server depends on:
ii  adduser 3.115
ii  init-system-helpers 1.48
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgoogle-perftools42.5-2.2
ii  libpcre32:8.39-3
ii  libpcrecpp0v5   2:8.39-3
ii  libsnappy1v51.1.3-3
ii  libssl1.0.2 1.0.2l-2+deb9u2
ii  libstdc++6  6.3.0-18+deb9u1
ii  libstemmer0d0+svn585-1+b2
ii  libyaml-cpp0.5v50.5.2-4
ii  lsb-base9.20161125
ii  mongodb-clients 1:3.2.11-2+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

mongodb-server recommends no packages.

mongodb-server suggests no packages.

-- Configuration Files:
/etc/mongodb.conf changed:
dbpath=/var/lib/mongodb
logpath=/var/log/mongodb/mongodb.log
logappend=true
bind_ip = 127.0.0.1
journal=true
cpu = true
verbose = true
objcheck = true
quota = true


-- no debconf information

Bug#891621: xfonts-intl-chinese: non-standard glyph for U+840D ('ping2')

[Toni Mueller]

Package: xfonts-intl-chinese
Version: 1.2.1-10
Severity: normal

Hi,

I'm not sure that this is the right package to report the bug against,
and I am not really sure that my assessment of the problem is correct,
but I do have the strong suspicion that I am. Anyway, when I write the
character 萍, I got the 'wrong' glyph in Anki and eg. terminator, but
got the right glyph inside Chromium. In both cases, fcitx is showing the
wrong glyph in the preview window. I have attached two screenshots
showing the two glyphs. The 'right' glyph seems to be the one which is
contained in the image that also contains the pronounciation, which
happens to be the bigger image.


Cheers,
Toni



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (90, 'testing'), (70, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages xfonts-intl-chinese depends on:
ii  xfonts-utils  1:7.7+4

xfonts-intl-chinese recommends no packages.

Versions of packages xfonts-intl-chinese suggests:
ii  emacs-intl-fonts  1.2.1-10
pn  xfonts-cjk
ii  xfonts-intl-chinese-big   1.2.1-10
ii  xserver-xephyr [xserver]  2:1.19.2-1+deb9u2
ii  xserver-xorg [xserver]1:7.7+19

-- no debconf information

Bug#891049: pgmodeler: version in stretch incompatible with db version in stretch

[Toni Mueller]

Package: pgmodeler
Version: 0.8.2-1+b1
Severity: normal


Hi!

I would like to use pgmodeler in Stretch, but the program can't work
with PostgreSQL 9.6, also in Stretch. I get an error message that only
versions up to 9.5 are supported, and that's the end of the story.


Cheers,
Toni



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (90, 'testing'), (70, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pgmodeler depends on:
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libpq59.6.6-0+deb9u1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5printsupport5   5.7.1+dfsg-3+b1
ii  libqt5svg55.7.1~20161021-2+b2
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-2.2+deb9u2
ii  pgmodeler-common  0.8.2-1

pgmodeler recommends no packages.

pgmodeler suggests no packages.

-- no debconf information

Bug#890772: python-httplib2: homepage needs updating

[Toni Mueller]

Package: python-httplib2
Version: 0.9.2+dfsg-1
Severity: minor
Tags: patch


Hi,

the homepage of this package has changed. I've seen that the old source
code has not seen updates in years, but at the new location, some bugs
have been fixed, and documentation has been improved.

I've attached a patch that updates the homepage.


Cheers,
Toni



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (90, 'testing'), (70, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-httplib2 depends on:
ii  ca-certificates  20161130+nmu1
ii  python   2.7.13-2

python-httplib2 recommends no packages.

python-httplib2 suggests no packages.

-- no debconf information
commit aa2bf6627e8dacbda999df4d70bda8fa10299589
Author: Toni Mueller <t...@debian.org>
Date:   Sun Feb 18 18:29:54 2018 +0100

updated homepage

diff --git a/debian/control b/debian/control
index b421211..b89f7a7 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: debhelper (>= 9),
python3-all (>= 3.1.2-10)
 Standards-Version: 3.9.8
 X-Python-Version: >= 2.4
-Homepage: https://github.com/jcgregorio/httplib2
+Homepage: https://github.com/httplib2/httplib2
 Vcs-Git: 
https://anonscm.debian.org/git/python-modules/packages/python-httplib2.git
 Vcs-Browser: 
https://anonscm.debian.org/cgit/python-modules/packages/python-httplib2.git
 

Bug#888209: isc-dhcp-client: hammers DHCP server if it cannot write lease file

[Toni Mueller]

Package: isc-dhcp-client
Version: 4.3.5-3+b2
Severity: normal


Hi,

I recently experienced a problem with dhclient issuing a ton of requests
in rapid fire mode in an endless loop because the file system where it
wanted to write its lease file, was mounted read-only. It got a new IP
everytime and added them all to the interface. It would be nice if
dhclient could just be content with having one IP address, and then stop
asking until the lease expires, regardless of the state of the file
system, instead of issuing dozens of DHCP requests per second.

I experien


Cheers,
--Toni++



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages isc-dhcp-client depends on:
ii  debianutils   4.8.4
ii  iproute2  4.14.1-1
ii  libc6 2.26-4
ii  libdns-export169  1:9.11.2+dfsg-5
ii  libisc-export166  1:9.11.2+dfsg-5

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.3.5-3+b2

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information

Bug#887787: lxc: CentOS 7 amd64 container can't be stopped

[Toni Mueller]

Hi,

the problem is not limited to CentOS. I just had a Debian container lock
up the same way, on the same host.


Cheers,
Toni

Bug#887787: lxc: CentOS 7 amd64 container can't be stopped

[Toni Mueller]

Package: lxc
Version: 1:2.0.7-2+deb9u1
Severity: normal


Hi,


I installed an unprivileged CentOS 7 container with

$ lxc-create -n centos -t download

after setting my system up according to the instructions given here:

https://wiki.debian.org/LXC


The resulting container starts as expected, but any attempt to shut it
down again, fails. The container remains responsive, but just does not
stop. Inside the container, the process list looks as follows:

$ lxc-attach -n centos
bash-4.2# ps auwwx
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 1  0.0  0.0  42544  2332 ?Ds   Jan20   0:00 /sbin/init
root   132  0.0  0.1 113380 13416 ?Ss   Jan20   0:00 /sbin/dhclient 
-1 -q -lf /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid 
-H centos eth0
root   191  0.0  0.0 115396  3160 ?Ss   Jan20   0:00 /bin/bash
root   192  0.0  0.0 107912   616 ?D+   Jan20   0:00 sync
root   193  0.0  0.0 115396  3064 ?Ss   Jan20   0:00 /bin/bash
root   194  0.0  0.0 151072  3564 ?R+   Jan20   0:00 ps auwwx
bash-4.2# 


In a different shell, things look like this:

$ lxc-attach -n centos
bash-4.2# halt -n -f
c^C^Z^C


(ie, no reaction)


In the kernel log of the host, I get a lot of these:


Jan 19 22:20:37 debian kernel: [39269.678133] INFO: task systemd:6381 blocked 
for more than 120 seconds.
Jan 19 22:20:37 debian kernel: [39269.678144]   Tainted: G   O
4.9.0-5-amd64 #1 Debian 4.9.65-3+deb9u2
Jan 19 22:20:37 debian kernel: [39269.678149] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 22:20:37 debian kernel: [39269.678154] systemd D0  6381   
6371 0x0104
Jan 19 22:20:37 debian kernel: [39269.678163]  976453d38000 
976553415800 976504ffafc0 97655fc98940
Jan 19 22:20:37 debian kernel: [39269.678170]  976500564480 
a7a7040b3bc0 a6802923 976504ffafc0
Jan 19 22:20:37 debian kernel: [39269.678176]  00ff976504ffafc0 
97655fc98940 976504161dc0 976504ffafc0
Jan 19 22:20:37 debian kernel: [39269.678181] Call Trace:
Jan 19 22:20:37 debian kernel: [39269.678194]  [] ? 
__schedule+0x233/0x6d0
Jan 19 22:20:37 debian kernel: [39269.678200]  [] ? 
schedule+0x32/0x80
Jan 19 22:20:37 debian kernel: [39269.678207]  [] ? 
rwsem_down_write_failed+0x1f9/0x360
Jan 19 22:20:37 debian kernel: [39269.678214]  [] ? 
kernfs_sop_show_options+0x30/0x30
Jan 19 22:20:37 debian kernel: [39269.678220]  [] ? 
call_rwsem_down_write_failed+0x13/0x20
Jan 19 22:20:37 debian kernel: [39269.678225]  [] ? 
down_write+0x29/0x40
Jan 19 22:20:37 debian kernel: [39269.678231]  [] ? 
grab_super+0x2b/0x90
Jan 19 22:20:37 debian kernel: [39269.678237]  [] ? 
sget_userns+0x163/0x490
Jan 19 22:20:37 debian kernel: [39269.678242]  [] ? 
kernfs_sop_show_path+0x40/0x40
Jan 19 22:20:37 debian kernel: [39269.678246]  [] ? 
kernfs_mount_ns+0x7a/0x220
Jan 19 22:20:37 debian kernel: [39269.678252]  [] ? 
cgroup_mount+0x334/0x810
Jan 19 22:20:37 debian kernel: [39269.678259]  [] ? 
mount_fs+0x36/0x150
Jan 19 22:20:37 debian kernel: [39269.678264]  [] ? 
vfs_kern_mount+0x62/0x100
Jan 19 22:20:37 debian kernel: [39269.678268]  [] ? 
do_mount+0x1cf/0xc80
Jan 19 22:20:37 debian kernel: [39269.678273]  [] ? 
SyS_mount+0x7e/0xd0
Jan 19 22:20:37 debian kernel: [39269.678279]  [] ? 
do_syscall_64+0x7c/0xf0
Jan 19 22:20:37 debian kernel: [39269.678285]  [] ? 
entry_SYSCALL64_slow_path+0x25/0x25
Jan 19 22:20:37 debian kernel: [39269.678294] INFO: task sync:6958 blocked for 
more than 120 seconds.
Jan 19 22:20:37 debian kernel: [39269.678300]   Tainted: G   O
4.9.0-5-amd64 #1 Debian 4.9.65-3+deb9u2
Jan 19 22:20:37 debian kernel: [39269.678303] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 19 22:20:37 debian kernel: [39269.678307] syncD0  6958   
6951 0x0104
Jan 19 22:20:37 debian kernel: [39269.678312]  976553fc4800 
 97653103a140 97655fcd8940
Jan 19 22:20:37 debian kernel: [39269.678318]  97655f00 
a7a706043df0 a6802923 9765500a5760
Jan 19 22:20:37 debian kernel: [39269.678324]  0286 
97655fcd8940 a7a706043df8 97653103a140
Jan 19 22:20:37 debian kernel: [39269.678329] Call Trace:
Jan 19 22:20:37 debian kernel: [39269.678335]  [] ? 
__schedule+0x233/0x6d0
Jan 19 22:20:37 debian kernel: [39269.678340]  [] ? 
schedule+0x32/0x80
Jan 19 22:20:37 debian kernel: [39269.678345]  [] ? 
rwsem_down_read_failed+0xf0/0x150
Jan 19 22:20:37 debian kernel: [39269.678350]  [] ? 
iput+0x7e/0x210
Jan 19 22:20:37 debian kernel: [39269.678356]  [] ? 
SyS_tee+0x390/0x390
Jan 19 22:20:37 debian kernel: [39269.678361]  [] ? 
call_rwsem_down_read_failed+0x14/0x30
Jan 19 22:20:37 debian kernel: [39269.678366]  [] ? 
down_read+0x1c/0x30
Jan 19 22:20:37 debian kernel: [39269.678371]  [] ? 
iterate_supers+0x9c/0x100
Jan 19 22:20:37 debian kernel: 

Bug#887764: dnsmasq: please add the homepage to the package

[Toni Mueller]

Package: dnsmasq
Version: 2.76-5+deb9u1
Severity: minor
Tags: patch


Hi,

I would like to have the homepage added to the package. The attached
patch accomplishes that.


Thanks,
Toni


-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (90, 'testing'), (70, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.76-5+deb9u1
ii  init-system-helpers  1.48
ii  netbase  5.4

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

-- no debconf information
commit 378b03da2b0cd79d688bf00e051521628e475bf7
Author: Toni Mueller <t...@debian.org>
Date:   Fri Jan 19 19:17:43 2018 +0100

adding a homepage

diff --git a/debian/control b/debian/control
index 035c830..e540918 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Build-depends: gettext, libnetfilter-conntrack-dev [linux-any],
libidn11-dev, libdbus-1-dev (>=0.61), libgmp-dev, 
nettle-dev (>=2.4-3), libbsd-dev [!linux-any]
 Maintainer: Simon Kelley <si...@thekelleys.org.uk>
+Homepage: http://www.thekelleys.org.uk/dnsmasq/doc.html
 Standards-Version: 3.9.8
 
 Package: dnsmasq

Bug#887109: postfix: missing /etc/postfix/postfix-files causes config check to always fail

[Toni Mueller]

Package: postfix
Version: 3.1.6-0+deb9u1
Severity: normal


Hi,

I read that in 3.1.4, you split the file /etc/postfix/postfix-files into
snippets which are then placed in /etc/postfix/postfix-files.d, but this
directory is also empty. I've just checked with the package in unstable,
and the situation is the same in that package, too.


Cheers,
Toni



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages postfix depends on:
ii  adduser3.115
ii  cpio   2.11+dfsg-6
ii  debconf [debconf-2.0]  1.5.61
ii  dpkg   1.18.24
ii  init-system-helpers1.48
ii  libc6  2.24-11+deb9u1
ii  libdb5.3   5.3.28-12+deb9u1
ii  libicu57   57.1-6+deb9u1
ii  libsasl2-2 2.1.27~101-g0780600+dfsg-3
ii  libssl1.1  1.1.0f-3+deb9u1
ii  lsb-base   9.20161125
ii  netbase5.4
ii  postfix-sqlite 3.1.6-0+deb9u1
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  python3  3.5.3-1

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]8.1.2-0.20160123cvs-4
ii  dovecot-core [dovecot-common]  1:2.2.27-3+deb9u1
ii  emacs25-lucid [mail-reader]25.1+1-4+deb9u1
ii  evolution [mail-reader]3.22.6-1+deb9u1
ii  libsasl2-modules   2.1.27~101-g0780600+dfsg-3
ii  mutt [mail-reader] 1.7.2-1
pn  postfix-cdb
ii  postfix-doc3.1.6-0+deb9u1
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
ii  postfix-pgsql  3.1.6-0+deb9u1
pn  procmail   
pn  resolvconf 
pn  sasl2-bin  
ii  sup-mail [mail-reader] 0.22.1-2
ii  ufw0.35-4
ii  wl-beta [mail-reader]  2.15.9+0.20161228-1

-- debconf information excluded

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Toni Mueller]

Hi Harlan,

On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote:
> It's been a while since we made the decision not to pull from upstream's
> git; Toni, I'd be happy to work with you on seeing if it's doable now.

I think I have a suitable package now, being as cheap as possible, but
it's off your git tree, which I took from 

  https://anonscm.debian.org/git/collab-maint/ansible.git
  
I had to change some things, though:

 * retrofit the docsite directory
 * adjust debian/control
 * adjust debian/rules

It's for 2.4.1, and it's lintian clean. My changes build both packages.

How can I best upload this stuff without disrupting yours, and without
creating an entirely new repository?

TIA!


Cheers,
--Toni++

Bug#879109: mutt: crash when pressing the wrong keys

[Toni Mueller]

Package: mutt
Version: 1.7.2-1
Severity: normal

Hi,

I am using awesome, but sometimes mistype something - eg. instead of
"Mod-4" for selecting the 4th label, I type "Ctrl-4". As a result, mutt
crashes. I get this error message while in the index:

$ mutt
GPGME: CMS protocol not available
Caught signal 3...  Exiting.



Cheers,
--Toni++



-- Package-specific info:
NeoMutt 20170113 (1.7.2)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0-4-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-2' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--with-target-sy
 stem-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20161229 (Debian 6.3.0-2) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-K2ak0h/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D
 _FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-K2ak0h/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -fno-delete-null-pointer-checks

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_FUTIMENS 
+HAVE_GETADDRINFO +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET 
+HAVE_LANGINFO_YESEXPR +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM 
+HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS 
+USE_COMPRESSED +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX 
+USE_GSS +USE_HCACHE +USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL 
+USE_SETGID +USE_SIDEBAR +USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compose-to-sender-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt
patch-forgotten-attachments-neomutt
patch-forwref-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-kyoto-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-reply-with-xorig-neomutt
patch-sensible-browser-neomutt
patch-sidebar-neomutt
patch-skip-quoted-neomutt
patch-status-color-neomutt

Bug#878303: genrsa manpage suggests using 1024 bit keys

[Toni Mueller]

Hi Sebastian,

On Fri, Oct 13, 2017 at 01:16:56PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-10-12 14:49:31 [+0100], Toni Mueller wrote:
> > I'm not suggesting a code change, but that the man page be updated to
> > suggest using 2048 bit keys instead.
> 
> That is one way to interpret it. The default is setting are 2048 bits.
> The paragraph describes a problem keys that 64bit in size or less. I
> would just drop the last sentence.

that's also one way to go about it, but while we are at it, can we
change the "should" to a "must"? Or can the software actually generate
primes which are even smaller than 64 bits? And what would be the
applicability of such small keys, anyway?


Cheers,
--Toni++

Bug#849086: small patch

[Toni Mueller]

Hi,

there are a ton of deprecation warnings in radiotray. I've just created
a small patch to silence one of them. Works for me - please test.


Cheers,
--Toni++

Index: radiotray-0.7.3/src/DbusFacade.py
===
--- radiotray-0.7.3.orig/src/DbusFacade.py
+++ radiotray-0.7.3/src/DbusFacade.py
@@ -19,7 +19,9 @@
 ##
 import dbus
 import dbus.service
-import dbus.glib
+from dbus.mainloop.glib import DBusGMainLoop
+
+DBusGMainLoop(set_as_default=True)
 
 
 class DbusFacade(dbus.service.Object):

Bug#878303: genrsa manpage suggests using 1024 bit keys

[Toni Mueller]

Package: openssl
Version: 1.1.0f-3
Severity: normal
Tags: security upstream


Hi,

the genrsa(1) manpage suggests that 1024 bits may be a typical key size
for RSA keys. I have to object - the Debian project deprecated 1024 bit
keys in GnuPG for a reason, and recently, there was also a bug in GnuPG
that allowed for 1024 bit keys to be broken.

I'm not suggesting a code change, but that the man page be updated to
suggest using 2048 bit keys instead.


Cheers,
--Toni++



-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages openssl depends on:
ii  libc6  2.24-11+deb9u1
ii  libssl1.1  1.1.0f-3

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20161130+nmu1

-- no debconf information

Bug#878075: high cpu load w/o any action

[Toni Mueller]

Package: circus
Version: 0.12.1+dfsg-1
Severity: normal


Hi,

I have a circus installation running, and it uses an inordinate amount
of CPU for itself - 5% for basically being idle. I find this very hard
to accept.

I've attached a screenshot which shows the situation.


Cheers,
Toni



-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages circus depends on:
ii  init-system-helpers  1.48
ii  python   2.7.13-2
ii  python-iowait0.1-1.1
ii  python-psutil5.0.1-1
ii  python-tornado   4.4.3-1
ii  python-zmq   16.0.2-2

Versions of packages circus recommends:
ii  python-gevent1.1.2-1
ii  python-gevent-websocket  0.9.3-1
ii  python-yaml  3.12-1

Versions of packages circus suggests:
ii  python-pygments  2.2.0+dfsg-1
pn  python-redis 

-- no debconf information

Bug#613892: git should only Recommend: git-man instead of Depends: git-man

[Toni Mueller]

Hi Jonathan,

On Wed, Oct 04, 2017 at 10:28:12AM -0700, Jonathan Nieder wrote:
> Thanks!  This is an excellent starting point.  I'll be happy to tweak
> this to make it configurable enough for upstream.  I'll also look into
> getting the Debian-specific text translated, which will be a new
> adventure for me.

thanks for the flowers!

> May I have your sign-off?  (See Documentation/SubmittingPatches
> section 5 "Certify your work" for what this means.)

Yes, of course. For me, it's 5(a). You can add this line at the
appropriate location:

Signed-off-by: Toni Mueller <m...@tonimueller.org>


Cheers,
--Toni++



signature.asc
Description: PGP signature

Bug#613892: git should only Recommend: git-man instead of Depends: git-man

[Toni Mueller]

Hi Jonathan,

On Tue, Oct 03, 2017 at 03:15:26PM -0700, Jonathan Nieder wrote:
> Have you read https://bugs.debian.org/613892#10?  Would you be
> interested in working on a patch for upstream Git to do that?  We can
> make the error message printed when manpages are missing a value set
> at compile time (see the Makefile for existing compile-time parameters
> like DEFAULT_EDITOR).  I'm happy to give pointers, etc. to anyone
> wanting to work on this.

I actually followed a different route and created a patch which is
Debian-specific. Please have a look - it is not yet polished in any way,
esp. all the translations are missing. The patch is against git in
unstable.


Cheers,
--Toni++

diff --git a/builtin/help.c b/builtin/help.c
index 334a849..c2a3670 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -32,6 +32,8 @@ enum help_format {
 	HELP_FORMAT_WEB
 };
 
+static const char *manpage_canary = "/usr/share/doc/git-man/copyright";
+
 static const char *html_path;
 
 static int show_all = 0;
@@ -342,8 +344,15 @@ static void show_man_page(const char *git_cmd)
 	struct man_viewer_list *viewer;
 	const char *page = cmd_to_page(git_cmd);
 	const char *fallback = getenv("GIT_MAN_VIEWER");
+	struct stat throwaway;
+	int find_canary = 0;
 
 	setup_man_path();
+	find_canary = stat(manpage_canary, );
+	if (find_canary == -1) {
+		printf(_("git: no man pages installed, please ask your system administrator to install the git-man package.\n"));
+		exit(0);
+	}
 	for (viewer = man_viewer_list; viewer; viewer = viewer->next)
 	{
 		exec_viewer(viewer->name, page); /* will return when unable */
diff --git a/debian/control b/debian/control
index 5c2eb20..bc8fc8b 100644
--- a/debian/control
+++ b/debian/control
@@ -27,9 +27,9 @@ Package: git
 Architecture: any
 Multi-Arch: foreign
 Depends: ${misc:Depends}, ${shlibs:Depends}, perl, liberror-perl,
- git-man (>> ${source:Upstream-Version}), git-man (<< ${source:Upstream-Version}-.)
 Pre-Depends: ${misc:Pre-Depends}
-Recommends: patch, less, ssh-client
+Recommends: patch, less, ssh-client, git-man (>> ${source:Upstream-Version}),
+ git-man (<< ${source:Upstream-Version}-.)
 Suggests: gettext-base, git-daemon-run | git-daemon-sysvinit,
  git-doc, git-el, git-email, git-gui, gitk, gitweb,
  git-cvs, git-mediawiki, git-svn

Bug#613892: git should only Recommend: git-man instead of Depends: git-man

[Toni Mueller]

Hi,

I can only agree with Nelson. These days, a lot of git installations are
non-interactive to begin with, as part of some service or so. Nobody is
ever going to read the manual pages in such use cases. It's just a waste
- and if the packages are being generated separately, anyway, weakening
the dependency seems to be just a logical consequence.

It would be nice if you could do it.

TIA!


Cheers,
--Toni++

Bug#869814: listens on *:67 regardless of configuration

[Toni Mueller]

Package: dnsmasq
Version: 2.76-5
Severity: normal

Hi,

I am running dnsmasq to provide DNS and DHCP services to some virtual
machines. Now, I want dnsmasq to listen *only* on the specified
interfaces. My configuration file thus reads:


 cut
log-queries=extra
log-facility=/var/log/dnsmasq.log

interface=docker0,virbr0
except-interface=lo,ovsbr0
bind-interfaces

server=10.99.1.1

rebind-localhost-ok

dhcp-range=172.17.42.10,172.17.42.253
dhcp-range=192.168.122.10,192.168.122.250

dhcp-host=fe:c9:3f:13:28:8a,192.168.122.10,stretch1
dhcp-host=fe:c9:3f:13:28:8b,192.168.122.11,stretch2
 cut


According to the documentation, that should make dnsmasq to open sockets
only on those two interfaces, for *any* services. But instead, I get
something like this (11322 is the PID of dnsmasq):


# lsof -p 11322 |grep -E 'UDP|TCP'
dnsmasq 11322 dnsmasq4u IPv4 13538201  0t0  UDP *:bootps 
dnsmasq 11322 dnsmasq6u IPv4 13538204  0t0  UDP 
172.17.42.1:domain 
dnsmasq 11322 dnsmasq7u IPv4 13538205  0t0  TCP 
172.17.42.1:domain (LISTEN)
dnsmasq 11322 dnsmasq8u IPv4 13538206  0t0  UDP mirror:domain 
dnsmasq 11322 dnsmasq9u IPv4 13538207  0t0  TCP mirror:domain 
(LISTEN)
dnsmasq 11322 dnsmasq   10u IPv6 13538208  0t0  UDP 
[fe80::bc9d:d8ff:fe13:394f]:domain 
dnsmasq 11322 dnsmasq   11u IPv6 13538209  0t0  TCP 
[fe80::bc9d:d8ff:fe13:394f]:domain (LISTEN)
# 

As you can see, the interface restriction for DNS works, but the
it does not work for DHCP. I tried adding a 'no-dhcp-interface'
statement to my configuration, but it had no effect.

This prevents a second dnsmasq server from starting on the same machine.


Cheers,
--Toni++



-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.76-5+b1
ii  init-system-helpers  1.48
ii  netbase  5.4

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
ii  resolvconf  1.79

-- Configuration Files:
/etc/default/dnsmasq changed [not included]
/etc/dnsmasq.conf changed [not included]

-- no debconf information

Bug#868706: no UI after minimizing and unminimizing in Awesome WM

[Toni Mueller]

Package: inkscape
Version: 0.92.1-1
Severity: important


Hi,

I'm using Awesome, the window manager, and ran into a big problem using
Inkscape. I actually can't remember having had this problem before,
because I have been using both Inkscape and Awesome for a long time,
although I use Inkscape only rarely.

The scenario: I start Inscape. Most things work nicely, but then, I
decided to minimize Inkscape, so it is only visible in the task bar at
the top of the screen. Then I tried to unminimize Inkscape again, to
continue to work on that image I was working on

The expected result: I would have expected Inkscape to properly display
again, and let me continue with my work.

The result: Inkscape did get as far as drawing a large grey rectangle
where Inkscape has been visible before, plus some white rectangles for
what were probably input windows (for eg. the font size), and that's it.
Please see the attached screenshot of the Inkscape window at that point.

As a consequence, I am unable to use Inkscape at this point.


Cheers,
--Toni++




-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-3+b2
ii  libatk1.0-02.22.0-1
ii  libatkmm-1.6-1v5   2.24.2-2
ii  libc6  2.24-11+deb9u1
ii  libcairo2  1.14.8-1
ii  libcairomm-1.0-1v5 1.12.0-1+b1
ii  libcdr-0.1-1   0.1.3-3+b1
ii  libdbus-1-31.10.18-1
ii  libdbus-glib-1-2   0.108-2
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgc1c2   1:7.4.2-8
ii  libgcc11:6.3.0-18
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-2
ii  libglibmm-2.4-1v5  2.50.0-1
ii  libgomp1   6.3.0-18
ii  libgsl22.3+dfsg-1
ii  libgtk2.0-02.24.31-2
ii  libgtkmm-2.4-1v5   1:2.24.5-1
ii  libgtkspell0   2.0.16-1.1
ii  libjpeg62-turbo1:1.5.1-2
ii  liblcms2-2 2.8-4
ii  libmagick++-6.q16-78:6.9.7.4+dfsg-11
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpangoft2-1.0-0  1.40.5-1
ii  libpangomm-1.4-1v5 2.40.1-3
ii  libpng16-161.6.28-1
ii  libpoppler-glib8   0.48.0-2
ii  libpoppler64   0.48.0-2
ii  libpopt0   1.16-10+b2
ii  libpotrace01.13-3
ii  librevenge-0.0-0   0.0.4-6
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libstdc++6 6.3.0-18
ii  libvisio-0.1-1 0.1.5-4+b1
ii  libwpg-0.3-3   0.3.1-3
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-2.2
ii  libxslt1.1 1.1.29-2.1
ii  python 2.7.13-2
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages inkscape recommends:
ii  aspell   0.60.7~20110707-3+b2
ii  fig2dev [transfig]   1:3.2.6a-2
ii  imagemagick  8:6.9.7.4+dfsg-11
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
ii  libimage-magick-perl 8:6.9.7.4+dfsg-11
ii  libwmf-bin   0.2.8.4-10.6
ii  python-lxml  3.7.1-1
ii  python-numpy 1:1.12.1-3
ii  python-scour 0.32-2
ii  transfig 1:3.2.6a-2

Versions of packages inkscape suggests:
pn  dia | dia-gnome  
pn  libsvg-perl  
pn  libxml-xql-perl  
ii  pstoedit 3.70-3+b2
pn  python-uniconvertor  
ii  ruby 1:2.3.3

-- no debconf information

Bug#863995: should not depend on inetd

[Toni Mueller]

Package: pure-ftpd-postgresql
Version: 1.0.36-3.2
Severity: wishlist


Hi Racke,

I am running this software under runit. Also, in the presence of
systemd, the requirement to have an inetd is pprobably rather weak.

It would be great if you could change the package accordingly.


Cheers,
Toni


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Bug#857661: Acknowledgement (awesome: systray frequently messed up)

[Toni Mueller]

Hi,

the situation occurred again, and I was able to take a screenshot, the
relevant bits of which you can find attached.


Enjoy,
--Toni++

Bug#857661: awesome: systray frequently messed up

[Toni Mueller]

Package: awesome
Version: 4.0-1
Severity: normal


Hi,

since a few weeks, my systray gets messed up. In particular, if I open
one of the programs listed there, the icons frequently get re-arranged,
but, much more annoying, awesome frequently starts to display the same
icon for several programs. Eg. at the moment, I can see two keyboard
icons (from fcitx), and two loudspeakers (from volti), where there
should have been a wicd and a clipit icon. If I manage to click the
'correct' icon, then the appropriate program will start - eg. clipit in
the case of one of the loudspeaker icons - but this is really, really
annoying. Sometimes, it flips back to normal, displaying every icon as
it should be. When I tried to take a screenshot, all icons flipped back
to normal, but it would be nice if awesome could always display the
correct icons by itself.


Cheers,
--Toni++



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages awesome depends on:
ii  dbus-x11  1.10.16-1
ii  gir1.2-freedesktop1.50.0-1+b1
ii  gir1.2-pango-1.0  1.40.3-3
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.16-1
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.50.3-1
ii  liblua5.1-0   5.1.5-8.1+b2
ii  libstartup-notification0  0.12-4
ii  libx11-6  2:1.6.4-3
ii  libxcb-cursor00.1.1-3
ii  libxcb-icccm4 0.4.1-1
ii  libxcb-keysyms1   0.4.0-1
ii  libxcb-randr0 1.12-1
ii  libxcb-render01.12-1
ii  libxcb-shape0 1.12-1
ii  libxcb-util0  0.3.8-3
ii  libxcb-xinerama0  1.12-1
ii  libxcb-xkb1   1.12-1
ii  libxcb-xrm0   1.0-2
ii  libxcb-xtest0 1.12-1
ii  libxcb1   1.12-1
ii  libxdg-basedir1   1.2.0-1
ii  libxkbcommon-x11-00.7.1-1
ii  libxkbcommon0 0.7.1-1
ii  lua-lgi   0.9.1-1
ii  menu  2.1.47

Versions of packages awesome recommends:
ii  feh2.18-1
ii  rlwrap 0.42-3
ii  x11-xserver-utils  7.7+7

awesome suggests no packages.

-- no debconf information

Bug#607234: problem persists in Stretch, upgrade severity?

[Toni Mueller]

Hi,

I can say that this problem persists in Stretch. I also went to copy a
lot of files to another machine, then went away, and found that rsync
was happily claiming to have written files correctly (I used -azvvcP),
but the target directory was empty.

This was with rsync 3.1.2-1 on amd64 on the sender side (Stretch), and
rsync 3.1.1-3 amd64 on the receiver side (Jessie).

I have ext4 file systems on both sides of the copy operation.

I think this bug should be upgraded to 'serious', since it could easily
result in data loss if the sender would delete files after transfer on
the sendind side.


Cheers,
--Toni++

Bug#856039: xserver-xorg-core: no keyboard and no mouse

[Toni Mueller]

Hi folks,

sorry for the late reply...

On Mon, Feb 27, 2017 at 06:17:42PM +0900, Michel Dänzer wrote:
> The client side has no impact on which drivers Xorg loads, or when. It
> looks like simply neither xserver-xorg-input-libinput nor
> xserver-xorg-input-evdev is installed.

the problem turned out to be this one. Once I installed
xserver-xorg-input-all, everything worked fine. But I have no idea how I
had arrived at this situation with the X server being installed, but not
any of the input drivers, because the xserver-xorg package (installed)
depends on one of those input packages. That's also why it did not occur
to me to look at this problem. I can also say for sure that nobody but
me is fiddling with the machine in question, at least not yet.


Sorry for the noise.


Thanks,
--Toni++

Bug#807648: zyne fails to start in stretch

[Toni Mueller]

Hi,

I just installed Zyne on a Stretch box and tried it out.

The error message is this:

$ zyne
Traceback (most recent call last):
  File "/usr/bin/zyne", line 4, in 
wxversion.select("2.8")
  File "/usr/lib/python2.7/dist-packages/wxversion.py", line 152, in select
raise VersionError("Requested version of wxPython not found")
wxversion.VersionError: Requested version of wxPython not found
$ 


However, if I change the offending code to say 
wxversion.select("3.0"), zyne starts, but shows a semi-functional user
interface. On the console, there are the following error messages:

$ zyne
18:05:00: Warning: Mismatch between the program and library build versions 
detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx 
containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1009,wx 
containers,compatible with 2.8).
pyo version 0.8.2 (uses double precision)
Gtk-Message: Failed to load module "canberra-gtk-module"
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching channel map
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, 
skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, 
skipping unlock

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/zyne/Resources/splash.py", line 71, in 
OnPaint
font.SetPixelSize((18,18))
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_gdi.py", line 2313, in 
SetPixelSize
return _gdi_.Font_SetPixelSize(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "IsOk()" failed at 
../src/gtk/font.cpp(337) in GetPointSize(): invalid font
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/zyne/Resources/splash.py", line 71, in 
OnPaint
font.SetPixelSize((18,18))
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_gdi.py", line 2313, in 
SetPixelSize
return _gdi_.Font_SetPixelSize(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "IsOk()" failed at 
../src/gtk/font.cpp(337) in GetPointSize(): invalid font
$ 



HTH


Cheers,
--Toni++

Bug#856039: xserver-xorg-core: no keyboard and no mouse

[Toni Mueller]

Package: xserver-xorg-core
Version: 2:1.19.1-4
Severity: grave
Justification: renders package unusable



Hi,

I installed Debian Testing/amd64 on a machine - basically a fresh
install - and yesterday ran an apt-get dist-upgrade to get the latest
stuff and finally set up users and X11. For Wheezy and Jessie, and also
for Testing up until about a few months ago, X11 did not need any
configuration for my machines. The hardware in question ran Wheezy
before, but for reasons outside of the scope of this problem, I had to
re-install instead of upgrading the machine. After firing up X11, I had
neither keyboard nor mouse. In /var/log/messages, I can see that eg. the
mouse is being recognised:

In the Xorg.0.log file, I can see:

Feb 24 14:26:19 debian kernel: [ 7412.497156] usb 3-1: new low-speed USB device 
number 2 using ohci-pci
Feb 24 14:26:19 debian kernel: [ 7412.710194] usb 3-1: New USB device found, 
idVendor=046d, idProduct=c040
Feb 24 14:26:19 debian kernel: [ 7412.710200] usb 3-1: New USB device strings: 
Mfr=1, Product=2, SerialNumber=0
Feb 24 14:26:19 debian kernel: [ 7412.710204] usb 3-1: Product: USB-PS/2 
Optical Mouse
Feb 24 14:26:19 debian kernel: [ 7412.710208] usb 3-1: Manufacturer: Logitech
Feb 24 14:26:19 debian kernel: [ 7412.719172] input: Logitech USB-PS/2 Optical 
Mouse as 
/devices/pci:00/:00:12.0/usb3/3-1/3-1:1.0/0003:046D:C040.0006/input/input20
Feb 24 14:26:19 debian kernel: [ 7412.719510] hid-generic 0003:046D:C040.0006: 
input,hidraw2: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on 
usb-:00:12.0-1/input0
Feb 24 14:26:19 debian mtp-probe: checking bus 3, device 2: 
"/sys/devices/pci:00/:00:12.0/usb3/3-1"
Feb 24 14:26:19 debian mtp-probe: bus: 3, device: 2 was not an MTP device

On the console, the keyboard works just fine, and on a different
computer, the mouse also works just fine. Unfortunately, this
installation is too new, so I don't really know when the problem was
introduced. I haven't tried to use X11 on this installation before, so I
only noticed the problem today.


Cheers,
Toni



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] RS880 [Radeon HD 4250] [1002:9715]

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170124 (Debian 6.3.0-5) ) #1 SMP Debian 4.9.6-3 (2017-01-28)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 27152 Feb  2 10:43 /var/log/Xorg.0.log
-rw-r--r-- 1 toni toni 27363 Feb 24 15:03 
/home/toni/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/toni/.local/share/xorg/Xorg.0.log):
-
[  9670.606] 
X.Org X Server 1.19.1
Release Date: 2017-01-11
[  9670.623] X Protocol Version 11, Revision 0
[  9670.628] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[  9670.634] Current Operating System: Linux debian 4.9.0-1-amd64 #1 SMP Debian 
4.9.6-3 (2017-01-28) x86_64
[  9670.634] Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-1-amd64 
root=/dev/mapper/ev0-root ro quiet
[  9670.645] Build Date: 20 January 2017  02:50:48AM
[  9670.650] xorg-server 2:1.19.1-4 (https://www.debian.org/support) 
[  9670.655] Current version of pixman: 0.34.0
[  9670.666]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  9670.666] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  9670.688] (==) Log file: "/home/toni/.local/share/xorg/Xorg.0.log", Time: 
Fri Feb 24 15:03:57 2017
[  9670.694] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  9670.694] (==) No Layout section.  Using the first Screen section.
[  9670.694] (==) No screen section available. Using defaults.
[  9670.694] (**) |-->Screen "Default Screen Section" (0)
[  9670.694] (**) |   |-->Monitor ""
[  9670.694] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  9670.694] (==) Automatically adding devices
[  9670.694] (==) Automatically enabling devices
[  9670.694] (==) Automatically adding GPU devices
[  9670.694] (==) Max clients allowed: 256, resource mask: 0x1f
[  9670.694] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  9670.694]Entry deleted from font path.
[  9670.694] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[  9670.694]Entry deleted 

Bug#855946: no sound on upgrade

[Toni Mueller]

Hi Elias,

On Fri, Feb 24, 2017 at 10:48:42AM -0300, Elías Alejandro wrote:
> What was your previous radiotray version?

it looks like something else caused the problem, because it only
appeared a few days ago, while the latest radiotray release was last
year (I should have checked earlier). However, just removing the
radiotray config file and having it generate a new one fixed it. I can't
tell which would be the relevant package in that case. :(

Please reassign as you see fit.


Cheers,
--Toni++

Bug#855946: no sound on upgrade

[Toni Mueller]

Package: radiotray
Version: 0.7.3-6
Severity: normal


Hi,

I have recently upgraded radiotray, and had no sound in radiotray after
that. Then I went to ~/.local/share and renamed the radiotray directory
to something else. After that, radiotray worked normally.


Cheers,
--Toni++



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages radiotray depends on:
ii  gir1.2-gtk-3.0 3.22.7-2
ii  gir1.2-keybinder-3.0   0.3.1-1
ii  gir1.2-notify-0.7  0.7.7-1
ii  gstreamer1.0-plugins-bad   1.10.3-1
ii  gstreamer1.0-plugins-base  1.10.3-1
ii  gstreamer1.0-plugins-good  1.10.3-1
ii  gstreamer1.0-plugins-ugly  1.10.3-1
ii  python-dbus1.2.4-1
ii  python-gi  3.22.0-2
ii  python-glade2  2.24.0-5.1
ii  python-gst-1.0 1.10.3-1
ii  python-lxml3.7.1-1
ii  python-xdg 0.25-4
pn  python:any 

radiotray recommends no packages.

radiotray suggests no packages.

-- no debconf information

Bug#854380: window no longer disappears after taking a screenshot and clicking the systray icon

[Toni Mueller]

Package: shutter
Version: 0.93.1-1.3
Severity: normal


Hi,

I have been using shutter for a while, and it used to be the case that
after taking a screenshot, I could click on the icon in the systray to
make the window with the screenshots, which appears after taking a
screenshot, disappear again.

Since a few weeks, this is no longer the case, and the only way to close
the window is to use the window manager's functionality to close a
client window. This is a nuisance from my POV, and I would like to have
the old behaviour back.
I am using the awesome window manager in a stand-alone fashion, and
started via 'startx'.

Cheers,
--Toni++


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages shutter depends on:
ii  imagemagick8:6.9.7.0+dfsg-2
ii  imagemagick-6.q16 [imagemagick]8:6.9.7.0+dfsg-2
ii  libfile-basedir-perl   0.07-1
ii  libfile-copy-recursive-perl0.38-1
ii  libfile-which-perl 1.21-1
ii  libglib-perl   3:1.324-1
ii  libgnome2-canvas-perl  1.002-4+b1
ii  libgnome2-gconf-perl   1.044-6+b1
ii  libgnome2-perl 1.046-3+b1
ii  libgnome2-vfs-perl 1.082-1+b3
ii  libgnome2-wnck-perl0.16-3+b3
ii  libgtk2-imageview-perl 0.05-2+b3
ii  libgtk2-perl   2:1.2499-1
ii  libgtk2-unique-perl0.05-2+b3
ii  libimage-magick-perl [perlmagick]  8:6.9.7.0+dfsg-2
ii  libjson-perl   2.90-1
ii  libjson-xs-perl3.030-1
ii  liblocale-gettext-perl 1.07-3+b1
ii  libnet-dbus-perl   1.1.0-4+b1
ii  libnet-dropbox-api-perl1.9-1
ii  libpath-class-perl 0.37-1
ii  libproc-processtable-perl  0.53-2
ii  libproc-simple-perl1.32-1
ii  librsvg2-common2.40.16-1
ii  libsort-naturally-perl 1.03-1
ii  libwww-mechanize-perl  1.83-1
ii  libwww-perl6.15-1
ii  libx11-protocol-other-perl 29-2
ii  libx11-protocol-perl   0.56-7
ii  libxml-simple-perl 2.22-1
ii  perlmagick 8:6.9.7.0+dfsg-2
ii  procps 2:3.3.12-3
ii  xdg-utils  1.1.1-1

Versions of packages shutter recommends:
ii  libgoo-canvas-perl 0.06-2+b3
ii  libgtk2-appindicator-perl  0.15-1+b4

Versions of packages shutter suggests:
pn  gnome-web-photo 
pn  libimage-exiftool-perl  
pn  libnet-dbus-glib-perl   
ii  nautilus-sendto 3.8.4-2

-- no debconf information

Bug#853756: debian-installer: no cryptsetup available in rescue mode

[Toni Mueller]

Hi KiBi,

On Tue, Jan 31, 2017 at 09:20:53PM +0100, Cyril Brulebois wrote:
> Control: notfound -1 20170112
> Control: tag -1 moreinfo
> 
> Toni Mueller <supp...@oeko.net> (2017-01-31):
> > I downloaded the testing installer using Jigdo from here:
> > http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo
> > because the Jessie installer in 8.7.1 would not work for me (#750586).
> 
> Well that isn't D-I Stretch RC 1 then. That one lives under:
>   http://cdimage.debian.org/cdimage/stretch_di_rc1/

I'm confused - the testing CD does not use the latest d-i?

> > > Were you prompted with a passphrase for the detected LUKS partition?
> > When I tried to run the installer in the "rescue" mode, it did not
> > prompt me with anything, but when it said something like "partition
> > disks", it did not have any crypto entries. On the console, it was
> > complaining about two missing modules, one of which ended with _crypto.
> > 
> > I looked for cryptsetup, but could not find it.
> 
> cryptsetup is the component installed in /target (the installed system),
> not what d-i uses.
> 
> Anyway, trying this image:
> f234f4aa708bdb226c0f412e85c37541c654526e  
> downloads/debian-testing-amd64-netinst.iso

I could set up an encrypted partition in the installation procedure,
just not access it during the rescue operation.

$ sha1sum debian-testing-amd64-netinst.iso 
1d50301e6eccba6b116253f323cf397cfccd88fe  debian-testing-amd64-netinst.iso

Your image is different. I downloaded "mine" this morning, btw.

> with a VM installed with guided encrypted LVM, and starting graphical
> rescue mode, I'm getting prompted for a passphrase to unlock /dev/sda5
> as expected, so d-i seems to behave properly.

I used the manual method, because I wanted to have a RAID1 underneath.

> > > Syslog might be interesting (vt4, or /var/log/syslog from another vt).
> > 
> > :/
> > 
> > I am sorry, but currently I can't produce those logs.
> 
> Given my test results above, we'll need those…

Ok. I'll see what I can do.


Cheers,
--Toni++

Bug#853756: debian-installer: no cryptsetup available in rescue mode

[Toni Mueller]

Hi KiBi,

On Tue, Jan 31, 2017 at 08:06:25PM +0100, Cyril Brulebois wrote:
> Toni Mueller <supp...@oeko.net> (2017-01-31):
> > I have a system which uses a LUKS partition, but when I started the
> > installer (fetched today) to repair something, it would not let me
> > decrypt the partition, and thus denied me access to the system.
> 
> Which image did you use? (Download URL?)

I downloaded the testing installer using Jigdo from here:

http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo

because the Jessie installer in 8.7.1 would not work for me (#750586).

> Were you prompted with a passphrase for the detected LUKS partition?

When I tried to run the installer in the "rescue" mode, it did not
prompt me with anything, but when it said something like "partition
disks", it did not have any crypto entries. On the console, it was
complaining about two missing modules, one of which ended with _crypto.

I looked for cryptsetup, but could not find it.

> Syslog might be interesting (vt4, or /var/log/syslog from another vt).

:/

I am sorry, but currently I can't produce those logs.



Cheers,
--Toni++

Bug#853756: debian-installer: no cryptsetup available in rescue mode

[Toni Mueller]

Package: debian-installer
Version: stretch RC1
Severity: important
Tags: d-i


Hi,

I have a system which uses a LUKS partition, but when I started the
installer (fetched today) to repair something, it would not let me
decrypt the partition, and thus denied me access to the system.


Cheers,
--Toni++



-- System Information:
Debian Release: 7.11
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'stable'), (90, 'testing'), (70, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Bug#853731: debian-installer: cannot remove RAID devices

[Toni Mueller]

Package: debian-installer
Version: stretch RC1
Severity: normal
Tags: d-i


Hi,

I am trying to reinstall a Debian machine which had an older version of
Debian on it, but now I want a slightly different partitioning scheme
for Stretch. The Debian installer offers me to delete the RAID
partitions, but then it continues to force me to have them and does not
allow me to make any changes to it. I already nuked the front part of
the disk with dd if=/dev/zero of=/dev/sda bs=1G count=1, and the same
for sdb, but the RAID still persists (should then be mdadm 0.9, because
that's at the end of the disk). It would be great if you could include
code to reliably kill pre-existing RAID partitions.

TIA!


Cheers,
--Toni++


-- System Information:
Debian Release: 7.11
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'stable'), (90, 'testing'), (70, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Bug#851619: new upstream release fixes a bag of CVEs

[Toni Mueller]

Hi,

On Mon, Jan 16, 2017 at 10:43:05PM +0100, Toni Mueller wrote:
> there is a new Ansible release, 2.2.1, which was published on 2017-01-11
> on releases.ansible.com, which fixes a bag of security holes, for which
> CVEs should already exist. Please take a look at

sorry, MY BAD.

The final 2.2.1 version was only released today, the packages released
on the 11th were only release candidates.


Cheers,
--Toni++

Bug#851619: new upstream release fixes a bag of CVEs

[Toni Mueller]

Hi Harlan,

On Mon, Jan 16, 2017 at 05:06:36PM -0500, Harlan Lieberman-Berg wrote:
> Happy to report that these have already been fixed through cherry-picks
> over the last five days or so.  2.2.1 has no security fixes not present
> in 2.2.0.0-4.

oh, great. I almost expected as much, but wanted to make really sure
because of the impact.

> We'll probably merge in 2.2.1 in the next couple of days to get the
> other bugfixes that are in there.

Sounds great. I was reading about some and already considered nagging
you about them.


Cheers,
--Toni++

Bug#851619: new upstream release fixes a bag of CVEs

[Toni Mueller]

Package: ansible
Version: 2.2.0.0-1
Severity: grave
Tags: security upstream


Hi,

there is a new Ansible release, 2.2.1, which was published on 2017-01-11
on releases.ansible.com, which fixes a bag of security holes, for which
CVEs should already exist. Please take a look at

https://www.computest.nl/advisories/CT-2017-0109_Ansible.txt


Cheers,
--Toni++



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ansible depends on:
ii  python-crypto 2.6.1-7
ii  python-httplib2   0.9.2+dfsg-1
ii  python-jinja2 2.8-1
ii  python-netaddr0.7.18-2
ii  python-paramiko   2.0.0-1
ii  python-pkg-resources  32.0.0-1
ii  python-yaml   3.12-1
pn  python:any

Versions of packages ansible recommends:
ii  python-kerberos   1.1.5-2+b2
ii  python-selinux2.6-3
pn  python-winrm  
ii  python-xmltodict  0.10.2-1

Versions of packages ansible suggests:
pn  cowsay   
ii  sshpass  1.06-1

-- Configuration Files:
/etc/ansible/ansible.cfg changed [not included]
/etc/ansible/hosts changed [not included]

-- no debconf information

Bug#849701: can't handle Chinese characters in the title bar

[Toni Mueller]

Hi,

On Thu, Jan 05, 2017 at 11:05:46PM +0100, Andreas Ronnquist wrote:
> By default, Sakura doesn't change title of window or Tab to the current
> folder name, as I get the impression it does on your system.

I think both bash and zsh, which I use, do it by default. There are some
escape sequences to control this behaviour.

> I have had a report previously by someone adding stuff to bashrc to
> make it so - have you something similar installed to your bashrc?

I use zsh, and my .zshrc, mostly generated, does this for me. However, I
used roxterm before and never had this problem.

> See the previous Sakura bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821783
> 
> and 
> http://tldp.org/HOWTO/Xterm-Title-3.html

Thank you! I'll take a look.

> As Sakura does set UTF-8 names correctly on both Window title and tab
> title for me, I am guessing that you are using some xterm escape
> sequences in a faulty way.

Hmmm - see above. Feel free to suggest something, regarding escape
sequences. I'm happy to test them.


Cheers,
--Toni++

Bug#849701: can't handle Chinese characters in the title bar

[Toni Mueller]

Hi Andreas,

On Thu, Jan 05, 2017 at 09:28:59PM +0100, Andreas Ronnquist wrote:
> Toni Mueller wrote:
> > I just discovered that Sakura apparently cannot handle UTF-8 window
> > titles. Please see the attached screenshot, which shows two carets
> > with question marks, where I would like to see two Chinese characters.
> 
> I have tried some UTF-8 characters and it works just fine for me -
> Also your image looks to me to show the tab title, and not the window
> title (just to be clear) - I have tried some UTF-8 characters both in
> window title and tab title, and it works fine for me.
> 
> Can you make sure that the font you are using (Both the font
> for the window title, and for the tab title, it might not be the
> same) supports the Chinese characters you want it to show?

the weird thing is, inside the shell, vi, emacs, firefox and
LibreOffice, I have no trouble writing those characters and seeing them
properly. But I don't know which fonts are involved. OTOH, I have about
every font package installed that is available in Debian, and if I 'ls'
to show the directory, it just works. I also didn't tune anything that I
am aware of.

I just made a test by going into a directory which has an all-Chinese
name. The tab title bar stops at the last directory with all-Latin
characters, and only displays a trailing slash. If I go into that other
directory with a mixed name, I get the question marks. I then made
another test and created a directory with a different mixed name, but
the same Chinese characters. Then I cd'ed into it, and the window title
changed to only display the latin part of the directory name. To me, it
seems that the display of Chinese characters is sort of "unstable".

FWIW, the Chinese chaacters in question are 老歌。


Cheers,
--Toni++

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Toni Mueller]

On Tue, Jan 03, 2017 at 09:14:59PM -0500, Harlan Lieberman-Berg wrote:
> Toni Mueller <t...@debian.org> writes:
> > I found them only on PyPI. Did you find them elsewhere?
> 
> We get them from releases.ansible.com.  Are the docs in the tarballs in
> PyPi?

Nope, there are only man pages.


Cheers,
--Toni++

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Toni Mueller]

Hi!

A happy new year, everyone!

On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote:
> Unfortunately, we don't build ansible off of the git repository, but
> rather from the released tarballs.

I found them only on PyPI. Did you find them elsewhere?

> It's been a while since we made the decision not to pull from upstream's
> git; Toni, I'd be happy to work with you on seeing if it's doable now.

Let's get the -doc package into stretch first if it's not too late
already.


Cheers,
--Toni++

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Toni Mueller]

Hi Evgeni,

On Fri, Dec 30, 2016 at 10:44:50PM +0100, Evgeni Golov wrote:
> On Fri, Dec 30, 2016 at 12:58:02AM +0100, Toni Mueller wrote:
> > documentation. This package aims to supply the documentation in HTML
> > form offline, so one should not need to go to the aoupstream website to
> > read it.
> 
> Which source is this built from?
> Do you basically want a mirror of https://docs.ansible.com/ansible/ in
> a Debian package?

I am building from a git clone of the ansible repository, and, more
specifically, from the tag v2.2.0.0-1.

> > Yours truly frequently suffers under bad network conditions, which make
> > reading the website infeasible or outright impossible, so I think the
> > package is useful.
> 
> If it is more than ansible-doc , then it certainly is.

My network conditions vary greatly, but too frequently, they are not
good enough to access anything on the Internet. Working on that, but
still, having a local copy of everything is very desirable from my POV.

> I just wonder whether it is sensible to built it from an own source,
> and not from the ansible source itself.

I found a very easy way to build everything from the ansible source, at
least for this tag.


Cheers,
--Toni++

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Toni Mueller]

Package: wnpp
Severity: wishlist
Owner: Toni Mueller <t...@debian.org>

* Package name: ansible-doc
  Version : 2.2.0.0-1
  Upstream Author : RedHat <i...@ansible.com>
* URL : http://www.ansible.com/
* License : GPL-3
  Programming Lang: HTML, JavaScript
  Description : Documentation for Ansible

Currently, the Ansible package in Debian lacks proper offline
documentation. This package aims to supply the documentation in HTML
form offline, so one should not need to go to the aoupstream website to
read it.

Yours truly frequently suffers under bad network conditions, which make
reading the website infeasible or outright impossible, so I think the
package is useful.

I hope I can collaborate with the maintainer of the ansible package to
maintain this package.
 

Bug#849701: can't handle Chinese characters in the title bar

[Toni Mueller]

Package: sakura
Version: 3.3.4-3
Severity: normal


Hi,

I just discovered that Sakura apparently cannot handle UTF-8 window
titles. Please see the attached screenshot, which shows two carets with
question marks, where I would like to see two Chinese characters.


Thank you!


Cheers,
--Toni++



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages sakura depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-8
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.2-2
ii  libgnutls30  3.5.7-2
ii  libgtk-3-0   3.22.5-1
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpcre2-8-0 10.22-2
ii  libvte-2.91-00.46.1-1
ii  zlib1g   1:1.2.8.dfsg-4

sakura recommends no packages.

sakura suggests no packages.

-- no debconf information

Bug#849374: gmtp: hangs forever, crashes on any USB change related to the device

[Toni Mueller]

Package: gmtp
Version: 1.3.10-1
Severity: important

Dear Maintainer,


   * What led up to the situation?

I wanted to use gmtp to transfer some files from my phone.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I set my phone to "MTP" and then started gmtp. Then I pressed the
'Connect' button. On the bottom, it says "no device detected", but on
the console, it says

** (gmtp:5587): WARNING **: Couldn't register with accessibility bus: 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.
Device 0 (VID=1004 and PID=633e) is a LG Electronics Inc. LG G Flex 2.
Android device detected, assigning default bug flags


(aside: It only says so after I manually changed the permissions
on the socket to g+rw).

   * What was the outcome of this action?

At this point, the application hangs.

   * What outcome did you expect instead?

I expected the application to show me the dialogue for
selecting a storage, then let me transfer files.

*** End of the template - remove these template lines ***


I waited for about 15 minutes without any progress. Under Jessie, it
would usually at some point time out and then proceed to the storage
selection dialogue. I then changed the phone's settings to 'PTP', at
which point the storage selection dialogue appears immediately. When I
press OK on that dialogue, the application crashes after spewing a ton
of

Error 7: Found a bad handle, trying to ignore it.

followed by

Error 2: PTP Layer error 02ff: get_handles_recursively(): could not get object 
handles.
Error 2: Error 02ff: PTP I/O Error
ERROR: Could not close session!
inep: usb_get_endpoint_status(): No such device
outep: usb_get_endpoint_status(): No such device
Rescan: How did I get called?
zsh: segmentation fault (core dumped)  gmtp

The last message is of course not from gmtp. Using GDB, I find:

$ gdb /usr/bin/gmtp core 
GNU gdb (Debian 7.11.1-2+b1) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/gmtp...(no debugging symbols found)...done.
[New LWP 5587]
[New LWP 5588]
[New LWP 5589]
[New LWP 5590]
[New LWP 5667]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `gmtp'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0040b20d in ?? ()
[Current thread is 1 (Thread 0x7f6e92275a80 (LWP 5587))]
(gdb) bt
#0  0x0040b20d in ?? ()
#1  0x7f6e91036f75 in g_closure_invoke () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0x7f6e91048f82 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x7f6e91051bcc in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x7f6e9105245b in g_signal_emit_by_name () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x7f6e910371a4 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x7f6e910518bd in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7f6e91051faf in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x7f6e9195ecfd in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7f6e9195ed65 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7f6e910371a4 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x7f6e910518bd in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x7f6e91051faf in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x7f6e9195d160 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x7f6e8bdfc038 in ffi_call_unix64 () from 
/usr/lib/x86_64-linux-gnu/libffi.so.6
#15 0x7f6e8bdfba9a in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#16 0x7f6e91037c8a in g_cclosure_marshal_generic_va () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x7f6e910371a4 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x7f6e910518bd in g_signal_emit_valist () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x7f6e91051faf in g_signal_emit () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 

Bug#848871: ansible-doc: please update to ansible 2.2

[Toni Mueller]

Package: ansible-doc
Version: 1.7.2+dfsg-2
Severity: normal


Dear Maintainer,

please consider re-creating the ansible-doc package to match the
ansible package. I frequently find it extremely helpful to have the docs
offline.

Thank you!


Kind regards,
--Toni++



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ansible-doc depends on:
ii  libjs-jquery  3.1.1-1
ii  libjs-underscore  1.8.3~dfsg-1

ansible-doc recommends no packages.

ansible-doc suggests no packages.

-- no debconf information

Bug#845613: Problem verified with Ansible 2.2

[Toni Mueller]

Hi,

after upgrading to Ansible 2.2, I still have the problem, but now get a
_much_ better error message: The Unix domain socket file name is too
long.

It turns out that the generated socket name had 111 characters, due to a
long, structured hostname, which includes the applications's and the
client's name, amongst other things, which is a local standard I can't
change.

IOW, fixing this problem is an upstream issue, requiring a diffent
socket naming scheme.


Cheers,
Toni

Bug#841750: XPS13 Jessie->Stretch: No sound

[Toni Mueller]

Hi Ben,

On Sat, Nov 19, 2016 at 11:04:07AM +, Ben Hutchings wrote:
> Perhaps it depends on whether you reboot or start from power-off?

I can't remember right now, but I think I tried both rebooting and
starting from power-off. The latter would be one of the first things
that come to mind...


Cheers,
--Toni++

Bug#845613: ansible: can't login to CentOS host by name

[Toni Mueller]

Package: ansible
Version: 2.1.1.0-1
Severity: important

Dear Maintainer,

I want to use Ansible to configure some CentOS 7 hosts. I can log in to
the host using my SSH key, using the name or the IP of the host without
any problems.

With Ansible, the situattion looks like this (sample):


$ ping  hostname
PING hostname (172.20.168.27) 56(84) bytes of data.
64 bytes from 172.20.168.27 (172.20.168.27): icmp_seq=1 ttl=62 time=1.96 ms
64 bytes from 172.20.168.27 (172.20.168.27): icmp_seq=2 ttl=62 time=1.91 ms
^C
--- hostname ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.913/1.940/1.968/0.051 ms
$ cat smallhosts

172.20.168.27
hostname

$ ansible -i smallhosts -m ping all
hostname | UNREACHABLE! => {
"changed": false, 
"msg": "Failed to connect to the host via ssh.", 
"unreachable": true
}
172.20.168.27 | SUCCESS => {
"changed": false, 
"ping": "pong"
}



As you can see, I listed the host twice in the inventory, once by IP,
and once by name. If I try to contact the host by name, ansible falls
over.

I don't expect anyone to fix this problem at this point, but would
rather use this case to support the other request for packaging 2.2,
which seems to have fixed several problems in this area.


Thank you!


Cheers,
Toni



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ansible depends on:
ii  python-crypto 2.6.1-6+b1
ii  python-httplib2   0.9.2+dfsg-1
ii  python-jinja2 2.8-1
ii  python-netaddr0.7.18-2
ii  python-paramiko   2.0.0-1
ii  python-pkg-resources  28.7.1-1
ii  python-yaml   3.12-1
pn  python:any

Versions of packages ansible recommends:
ii  python-selinux  2.6-3

Versions of packages ansible suggests:
ii  sshpass  1.06-1

-- no debconf information

Bug#841750: XPS13 Jessie->Stretch: No sound

[Toni Mueller]

Hi Adrian,


On Sun, Oct 23, 2016 at 10:41:57AM +0300, Adrian Bunk wrote:
> Control: reassign -1 src:linux
> 
> On Sun, Oct 23, 2016 at 06:57:53AM +0800, Toni Mueller wrote:
> > Package: upgrade-reports
> > Severity: important


> > recently, I felt the need to upgrade my XPS 13 laptop (2013 model?) from
> > Jessie to Stretch, but have not had any sound ever since.
> > 
> > To be more precise, I had no sound ever after trying the 4.7 backported
> > kernel on Jessie, which was what originally prompted me to upgrade to
> > Stretch.
> >...
> 
> thanks for your report.
> 
> This sounds like a bug in the kernel, I'm moving it there.

in the meantime, the problem was resolved. Short story: After booting
the 4.x kernel for the first time, sound disappeared. I recently did a
factory reset in the BIOS, and sound re-appeared.

So yes, at this point, I also suspect that there is some problem with
the kernel, but why this seemingly happens only on upgrade, I don't
know.


Cheers,
--Toni++

Bug#843381: ffproxy: server does not start

[Toni Mueller]

Package: ffproxy
Version: 1.6-11
Severity: important


Dear Maintainer,


I installed ffproxy and then tried to start it.  Out of the box, ffproxy
does not start, complaining that it is unable to open a file
'db/access.ip'. However, for all locations I tried, this file is there.
I tried to modify the chroot settings and the database path settings,
but to no avail. So far, I have been unable to start ffproxy. Here is an
attempt where I try to start it by hand:

# strace ffproxy -r  /var/lib/ffproxy/etc/ffproxy

execve("/usr/bin/ffproxy", ["ffproxy", "-r", "/var/lib/ffproxy/etc/ffproxy"], 
[/* 61 vars */]) = 0
brk(NULL)   = 0x127d000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fd3ae472000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=155030, ...}) = 0
mmap(NULL, 155030, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fd3ae44c000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libnsl.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320?\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=89064, ...}) = 0
mmap(NULL, 2194008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fd3ae03b000
mprotect(0x7fd3ae04f000, 2097152, PROT_NONE) = 0
mmap(0x7fd3ae24f000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7fd3ae24f000
mmap(0x7fd3ae251000, 6744, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fd3ae251000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\3\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1685264, ...}) = 0
mmap(NULL, 3791264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fd3adc9d000
mprotect(0x7fd3ade32000, 2093056, PROT_NONE) = 0
mmap(0x7fd3ae031000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0x7fd3ae031000
mmap(0x7fd3ae037000, 14752, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fd3ae037000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fd3ae44a000
arch_prctl(ARCH_SET_FS, 0x7fd3ae44a700) = 0
mprotect(0x7fd3ae031000, 16384, PROT_READ) = 0
mprotect(0x7fd3ae24f000, 4096, PROT_READ) = 0
mprotect(0x609000, 4096, PROT_READ) = 0
mprotect(0x7fd3ae475000, 4096, PROT_READ) = 0
munmap(0x7fd3ae44c000, 155030)  = 0
brk(NULL)   = 0x127d000
brk(0x129e000)  = 0x129e000
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=414, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=414, ...}) = 0
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\0\0\0\3\0\0\0\0"..., 4096) 
= 414
lseek(3, -249, SEEK_CUR)= 165
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\0\0\0\3\0\0\0\0"..., 4096) 
= 249
close(3)= 0
getpid()= 11012
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = 0
sendto(3, "<14>Nov  6 10:07:34 FFPROXY(mast"..., 66, MSG_NOSIGNAL, NULL, 0) = 66
open("/etc/ffproxy/ffproxy.conf", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=3708, ...}) = 0
read(4, "#\n# Debianized configuration fil"..., 4096) = 3708
read(4, "", 4096)   = 0
close(4)= 0
chdir("./db")   = 0
open("db/access.ip", O_RDONLY)  = -1 ENOENT (No such file or directory)
sendto(3, "<11>Nov  6 10:07:34 FFPROXY(mast"..., 90, MSG_NOSIGNAL, NULL, 0) = 90
dup(2)  = 4
fcntl(4, F_GETFL)   = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(4, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
write(4, "unable to open file db/access.ip"..., 60unable to open file 
db/access.ip: No such file or directory
) = 60
close(4)= 0
exit_group(1)   = ?
+++ exited with 1 +++


And here is the configuration file that I used, with blank and
comment lines removed (/etc/ffproxy/ffproxy.conf):


child_processes 10
bind_ipv4 yes
bind_ipv6 no
port 8080
use_ipv6 no
use_syslog yes
log_all_requests no
forward_proxy_port 0
forward_proxy_ipv6 no
accel_port 0
accel_user_host yes
use_keep_alive yes
unrestricted_connect no
timeout_connect 20
backlog_size 4
daemonize yes
chroot_dir /var/lib/ffproxy/etc/ffproxy
db_files_path ./db

Bug#842223: seahorse: can't unlock Gnome keyring

[Toni Mueller]

Package: seahorse
Version: 3.20.0-2
Severity: important

Dear Maintainer,

I want to use seahorse to unlock my Gnome keyring, which I need for
some other app (Evolution) that depends on it.

Since my latest upgrade, I am no longer being asked for a password to
unlock it with this pop-up (which app produces that?), so I thought I'd
use seahorse instead. In seahorse, I can see the keyring, then
right-click and select 'Unlock', and then nothing happens. As a result
of this, the keyring does not get unlocked.

I would expect a password dialogue to appear to let me unlock the
keyring.

FWIW, I use awesome as a "desktop", but need to use Evolution to access
my email on an Exchange server. However, switching to Gnome entirely is
not an option.


Cheers,
Toni



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages seahorse depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gcr  3.20.0-3
ii  gnome-keyring3.20.0-3
ii  gnupg2.1.15-4
ii  libatk1.0-0  2.22.0-1
ii  libavahi-client3 0.6.32-1
ii  libavahi-common3 0.6.32-1
ii  libavahi-glib1   0.6.32-1
ii  libc62.24-5
ii  libgck-1-0   3.20.0-3
ii  libgcr-base-3-1  3.20.0-3
ii  libgcr-ui-3-13.20.0-3
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgpgme11   1.7.0-1
ii  libgtk-3-0   3.22.1-1
ii  libldap-2.4-22.4.42+dfsg-2+b3
ii  libsecret-1-00.18.5-2
ii  libsoup2.4-1 2.56.0-1

Versions of packages seahorse recommends:
ii  openssh-client  1:7.3p1-1

seahorse suggests no packages.

-- no debconf information

Bug#841750: XPS13 Jessie->Stretch: No sound

[Toni Mueller]

Package: upgrade-reports
Severity: important


Hi folks,

recently, I felt the need to upgrade my XPS 13 laptop (2013 model?) from
Jessie to Stretch, but have not had any sound ever since.

To be more precise, I had no sound ever after trying the 4.7 backported
kernel on Jessie, which was what originally prompted me to upgrade to
Stretch.

The device seems to be there:

# lspci -v
...

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family 
High Definition Audio Controller (rev 04)
Subsystem: Dell 7 Series/C210 Series Chipset Family High Definition Audio 
Controller
Flags: bus master, fast devsel, latency 0, IRQ 28
Memory at d051 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [130] Root Complex Link
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel


But Pulseaudio does not find it. I already deleted ~/.config/pulse, but
to no effect. pavucontrol shows only "Digital Stereo" and two "Digital
Surround", but all being "unplugged".

Heeding the advice to look into the BIOS, I found no settings relating
to sound, and that my BIOS is A09, which is well above the recommended
A02.

I installed firmware-linux-nonfree and firmware-intel-sound, but to no
avail.


Cheers,
Toni


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#841486: sakura: too many tabs -> window extends to other virtual screens

[Toni Mueller]

Package: sakura
Version: 3.3.4-2
Severity: normal

Dear Maintainer,

when I open enough tabs that the tab titles do not fit anymore, sakura
changes the window size to make the titles fit. The result is that I can
see parts of the terminal on a different monitor, obscuring other
windows there (at least in conjunction with awesome).

I did not find a way to adjust this behaviour.


Cheers,
Toni


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages sakura depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-3
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgnutls30  3.5.4-2
ii  libgtk-3-0   3.22.1-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libvte-2.91-00.46.0-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

sakura recommends no packages.

sakura suggests no packages.

-- no debconf information

Bug#838430: volti: traceback on startup

[Toni Mueller]

Hi James,

On Sat, Sep 24, 2016 at 01:33:59PM +0800, Toni Mueller wrote:
> On Wed, Sep 21, 2016 at 10:19:28AM +0100, James Cowgill wrote:
> > You could try this:
> > sed -i 's/card_index = 0/card_index = 1/' ~/.config/volti/config
> 
> it worked!

just as another data point: Today, I've tried the same on Jessie with a
the 4.7 kernel from backports, but the result is this:

$ volti
[alsactrl.py:__init__:41] can't open Master control for card PCH, trying to 
select first available mixer channel

[alsactrl.py:__init__:49] can't open first available control for card PCH
error: list index out of range
Xlib.protocol.request.QueryExtension
Traceback (most recent call last):
  File "/usr/bin/volti", line 53, in 
volti = main.VolumeTray()
  File "/usr/lib/volti/volti/main.py", line 124, in __init__
self.watchid = gobject.io_add_watch(fd, eventmask, self.update)
TypeError: an integer is required
$ 

It looks like the Pulseaudio system does not find the card, and volti
subsequently barfs.


Cheers,
--Toni++

Bug#838430: volti: traceback on startup

[Toni Mueller]

Hi James,

On Wed, Sep 21, 2016 at 10:19:28AM +0100, James Cowgill wrote:
> You could try this:
> sed -i 's/card_index = 0/card_index = 1/' ~/.config/volti/config

it worked!

Thank you!


Cheers,
--Toni++

Bug#838430: volti: traceback on startup

[Toni Mueller]

Hi James,

On Wed, Sep 21, 2016 at 10:19:28AM +0100, James Cowgill wrote:
> ALSA/pulseaudio may have rearranged your cards when you upgraded.

hmmm. I don't think I logged in as a normal user before the upgrade, it
just happened to be that the installer installed Jessie from a Wheezy
stick, but thank you for the tip!

> However I think volti should at least detect the correct card and not
> crash, so I'll leave the bug open.

Not crashing would be good. Thank you!


Cheers,
--Toni++

Bug#838430: volti: traceback on startup

[Toni Mueller]

Package: volti
Version: 0.2.3-7
Severity: important

Dear Maintainer,

I can't use volti because everytime I try to start it, it crashes:

$ volti
[alsactrl.py:__init__:41] can't open Master control for card HDMI,
trying to select first available mixer channel

[alsactrl.py:__init__:49] can't open first available control for card
HDMI
error: list index out of range
Traceback (most recent call last):
  File "/usr/bin/volti", line 52, in 
volti = main.VolumeTray()
  File "/usr/lib/volti/volti/main.py", line 124, in __init__
self.watchid = gobject.io_add_watch(fd, eventmask, self.update)
TypeError: an integer is required
$ 

This happens on a Dell Latitude E7440, which I have installed with
Jessie and then immediately upgraded to Stretch.


Cheers,
Toni



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages volti depends on:
ii  python-alsaaudio  0.7-1
ii  python-dbus   1.2.4-1
ii  python-gobject3.21.92-1
ii  python-gtk2   2.24.0-5
ii  python-xlib   0.14+20091101-5
pn  python:any

volti recommends no packages.

volti suggests no packages.

-- no debconf information