Bug#982894: How to reproduce

2021-02-17 Thread Johannes Weißl
Sorry for the spelling in my original mail, I was too tired.

Here is how you can reproduce the bug:

root@ec2-instance:~# cat /etc/resolv.conf
domain eu-central-1.compute.internal
search eu-central-1.compute.internal
nameserver 172.31.0.2
root@ec2-instance:~# fallocate -l 1TB /etc/bigfile
fallocate: fallocate failed: No space left on device
root@ec2-instance:~# dhclient
RTNETLINK answers: File exists
/sbin/dhclient-script: 54: echo: echo: I/O error
/sbin/dhclient-script: 72: echo: echo: I/O error
/sbin/dhclient-script: 77: echo: echo: I/O error
root@ec2-instance:~# cat /etc/resolv.conf
root@ec2-instance:~# rm /etc/bigfile

With my patch, dhclient leaves the valid /etc/resolv.conf unmodified instead of 
making it empty / corrupt.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211261 for a similar 
problem with dhcp3-client.



Bug#982894: isc-dhcp-client: Empty /etc/resolv.conf if root partition is full

2021-02-15 Thread Johannes Weißl
Package: isc-dhcp-client
Version: 4.4.1-2
Severity: important
Tags: patch

The Debian version of /sbin/dhclient-script creates a temporary file next to
/etc/resolv.conf, and fills it with information. Then it replaces
/etc/resolv.conf with the temporary file. So far so good.

The problem appears when the root partition is full. The temporary file is
creates, but filling it with informations is not possible anymore (echo "..." >
temporary_resolv_conf fails). BUT: Instead of aborting, dhclient-script still
replaced the perfectly good /etc/resolv.conf with an empty one.

This problem appears a lot on AWS EC2 instances (are configured using DHCP,
despite being servers).



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

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages isc-dhcp-client depends on:
ii  debianutils4.8.6.1
ii  iproute2   4.20.0-2+deb10u1
ii  libc6  2.28-10
ii  libdns-export1104  1:9.11.5.P4+dfsg-5.1+deb10u2
ii  libisc-export1100  1:9.11.5.P4+dfsg-5.1+deb10u2

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.1-2

Versions of packages isc-dhcp-client suggests:
ii  avahi-autoipd 0.7-4+b1
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information
diff -Naur isc-dhcp-4.4.1.old/debian/dhclient-script.hurd 
isc-dhcp-4.4.1.new/debian/dhclient-script.hurd
--- isc-dhcp-4.4.1.old/debian/dhclient-script.hurd  2018-12-11 
04:55:12.0 +0100
+++ isc-dhcp-4.4.1.new/debian/dhclient-script.hurd  2021-02-15 
23:45:10.628260983 +0100
@@ -26,7 +26,7 @@
 rm -f $new_resolv_conf
 
 if [ -n "$new_domain_name" ]; then
-echo domain ${new_domain_name%% *} >>$new_resolv_conf
+echo domain ${new_domain_name%% *} >>$new_resolv_conf || exit 1
 fi
 
 if [ -n "$new_domain_search" ]; then
@@ -42,17 +42,17 @@
 new_domain_search="$new_domain_name 
$new_domain_search"
 fi
 fi
-echo "search ${new_domain_search}" >> $new_resolv_conf
+echo "search ${new_domain_search}" >> $new_resolv_conf || exit 1
 elif [ -n "$new_domain_name" ]; then
-echo "search ${new_domain_name}" >> $new_resolv_conf
+echo "search ${new_domain_name}" >> $new_resolv_conf || exit 1
 fi
 
 if [ -n "$new_domain_name_servers" ]; then
for nameserver in $new_domain_name_servers; do
-   echo nameserver $nameserver >>$new_resolv_conf
+   echo nameserver $nameserver >>$new_resolv_conf || exit 1
 done
 else # keep 'old' nameservers
-sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p 
/etc/resolv.conf >>$new_resolv_conf
+sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p 
/etc/resolv.conf >>$new_resolv_conf || exit 1
 fi
 
 chown --reference=/etc/resolv.conf $new_resolv_conf
@@ -64,15 +64,15 @@
 rm -f $new_resolv_conf
 
 if [ -n "$new_dhcp6_domain_search" ]; then
-echo "search ${new_dhcp6_domain_search}" >> $new_resolv_conf
+echo "search ${new_dhcp6_domain_search}" >> $new_resolv_conf || 
exit 1
 fi
 
 if [ -n "$new_dhcp6_name_servers" ]; then
 for nameserver in $new_dhcp6_name_servers; do
-echo nameserver $nameserver >>$new_resolv_conf
+echo nameserver $nameserver >>$new_resolv_conf || exit 1
 done
 else # keep 'old' nameservers
-sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p 
/etc/resolv.conf >>$new_resolv_conf
+sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p 
/etc/resolv.conf >>$new_resolv_conf || exit 1
 fi
 
 chown --reference=/etc/resolv.conf $new_resolv_conf
diff -Naur isc-dhcp-4.4.1.old/debian/dhclient-script.linux 
isc-dhcp-4.4.1.new/debian/dhclient-script.linux
--- isc-dhcp-4.4.1.old/debian/dhclient-script.linux 2018-12-11 
04:55:12.0 +0100
+++ isc-dhcp-4.4.1.new/debian/dhclient-script.linux 2021-02-15 
23:45:10.156260808 +0100
@@ -51,7 +51,7 @@
 rm -f $new_resolv_conf
 
 if [ -n "$new_domain_name" ]; then
-echo domain ${new_domain_name%% *} >>$new_resolv_conf
+echo domain ${new_domain_name%% *} >>$new_resolv_conf || exit 1
 fi
 
 if [ -n "$new_domain_search" ]; then
@@ -67,17 +67,17 @@
 new_domain_search="$new_domain_name $new_domain_search"

Bug#844593: erlang-wx: WX broken due to "-fno-pie -no-pie" CFLAGS/LDFLAGS

2016-11-17 Thread Johannes Weißl
Package: erlang-wx
Version: 1:19.1.6+dfsg-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

The solution of bug #842998 breaks WX:

1> observer:start().
{error,{{load_driver,"No driver found"},
[{wxe_server,start,1,[{file,"wxe_server.erl"},{line,65}]},
 {wx,new,1,[{file,"wx.erl"},{line,115}]},
 {observer_wx,init,1,[{file,"observer_wx.erl"},{line,104}]},
 {wx_object,init_it,6,[{file,"wx_object.erl"},{line,355}]},
 {proc_lib,init_p_do_apply,3,
   [{file,"proc_lib.erl"},{line,247}]}]}}

=ERROR REPORT 17-Nov-2016::10:12:15 ===
ERROR: Could not find 'wxe_driver.so' in: /usr/lib/erlang/lib/wx-1.7.1/priv

What works is to remove "-fno-pie -no-pie" from CFLAGS and LDFLAGS in
debian/rules and to apply the following two upstream patches:

- 
https://github.com/erlang/otp/commit/5aa13e16ae81050509fceaf603650fc8594af7ec.patch
- 
https://github.com/erlang/otp/commit/edfa3b87542687baa2530a41241eb83d9afda1fb.patch

(both are necessary).



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, '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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages erlang-wx depends on:
ii  erlang-base-hipe  1:19.1.6+dfsg-1

erlang-wx recommends no packages.

Versions of packages erlang-wx suggests:
ii  erlang   1:19.1.6+dfsg-1
ii  erlang-doc   1:19.1.6+dfsg-1
ii  erlang-manpages  1:19.1.6+dfsg-1

-- no debconf information



Bug#842998: erlang-base-hipe: OTP / HiPE broken with GCC 6.2

2016-11-02 Thread Johannes Weißl
Package: erlang-base-hipe
Version: 1:19.1.5+dfsg-1
Severity: grave
Tags: upstream
Justification: renders package unusable

HiPE in the OTP 19.1.5 Debian package is broken (at least on amd64), because it
was built with GCC 6.2. See also upstream report:

http://erlang.org/pipermail/erlang-questions/2016-November/090753.html



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages erlang-base-hipe depends on:
ii  adduser  3.115
ii  init-system-helpers  1.45
ii  libc62.24-5
ii  libsctp1 1.0.17+dfsg-1
ii  libsystemd0  231-9
ii  libtinfo56.0+20160917-1
ii  procps   2:3.3.12-2
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages erlang-base-hipe recommends:
ii  erlang-crypto1:19.1.5+dfsg-1
ii  erlang-syntax-tools  1:19.1.5+dfsg-1
ii  libsctp1 1.0.17+dfsg-1

Versions of packages erlang-base-hipe suggests:
ii  erlang   1:19.1.5+dfsg-1
ii  erlang-doc   1:19.1.5+dfsg-1
ii  erlang-manpages  1:19.1.5+dfsg-1
ii  erlang-tools 1:19.1.5+dfsg-1

-- no debconf information



Bug#810475: python-astroid: Pylint 1.4.4 does not work with Astroid 1.4.x

2016-01-08 Thread Johannes Weißl
Package: python-astroid
Version: 1.4.3-1
Severity: grave
Justification: renders package unusable

The current versions of pylint (1.4.4) and python-astroid (1.4.3) in Debian
Stretch do not work together, causing errors like:

Problem importing module classes.py: cannot import name InferenceContext
E0602:...,...: ...: Undefined variable

See also
https://bitbucket.org/logilab/pylint/issues/720/problem-importing-module-classespy-cannot



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

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

Versions of packages python-astroid depends on:
ii  python-lazy-object-proxy  1.2.1-1
ii  python-logilab-common 1.0.2-1
ii  python-six1.10.0-1
ii  python-wrapt  1.8.0-5+b1
pn  python:any

python-astroid recommends no packages.

python-astroid suggests no packages.

-- no debconf information



Bug#788066: unattended-upgrades: Security updates not installed since last upgrade of unattended-upgrades package

2015-06-20 Thread Johannes Weißl
On Wed, Jun 17, 2015 at 06:44AM -0700, Vagrant Cascadian wrote:
 Obviously individual users can manually upgrade unattended-upgrades
 manually via proposed-updates, but that leaves all the users expecting
 unattended-upgrades to be installing upgrades unattended without
 security updates.
 
 It may make sense to get unattended-upgrades updated through security
 updates, rather than waiting until a point release to propegate this
 fix...

This does not work: The buggy version of unattended-unattended won't
upgrade itself, even if the package comes through security updates.

Johannes


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



Bug#788066: unattended-upgrades: Security updates not installed since last upgrade of unattended-upgrades package

2015-06-20 Thread Johannes Weißl
On Wed, Jun 17, 2015 at 10:22AM +0200, Michael Vogt wrote:
  I can confirm this, the fix of #783690 seems to be faulty. [...]
 
 Sorry for this, this is a brown-paperbag bug in my upload, I uploaded
 a new 0.83.3.2 to stable-proposed-updates [1]

I tested the new version from stable-proposed-updates, and it solves the 
problem!

Thanks,
Johannes


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



Bug#788066: unattended-upgrades: Security updates not installed since last upgrade of unattended-upgrades package

2015-06-10 Thread Johannes Weißl
On Mon, Jun 08, 2015 at 11:51AM +0200, Hans Yntema wrote:
 Since this last upgrade, security updates don't get installed automatically.

I can confirm this, the fix of #783690 seems to be faulty. It uses
Allowed-Origins instead of Origins-Pattern, which does not seem to
support codenames (e.g. Jessie) nor matching only security updates.

This works:

Unattended-Upgrade::Origins-Pattern {
origin=${distro_id},codename=${distro_codename},label=Debian-Security;
}

(drop the ,label=Debian-Security if you want normal updates as well,
as suggested in #787945)


With Allowed-Origins this works, but installs not only security
updates:

Unattended-Upgrade::Allowed-Origins {
${distro_id}:stable;
}

Johannes


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



Bug#768027: New patch

2015-02-24 Thread Johannes Weißl
Hi,

A proper patch for this problem has been committed:
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixesid=f37b5c2be8979993efee2da50b51126e3908eb8b

I did a backport of this patch to Debian Jessie kernel 3.16.7-ckt4-3
(solves the bug on my Samsung N210 netbook):

https://bugs.freedesktop.org/attachment.cgi?id=113497

Any chances that this will make it into Jessie?

Regards,
Johannes


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



Bug#775785: trac-mercurial 1.0.0.4

2015-02-01 Thread Johannes Weißl
On Wed, Jan 28, 2015 at 12:26AM +0500, Andrey Rahmatullin wrote:
 On Tue, Jan 20, 2015 at 02:12:41AM +0100, Johannes Weißl wrote:
  An alternative would be to directly package version 1.0.0.4 (c91c42e), [...]
 
 The diff is quite large and contains unrelated changes like removing
 trailing whitespace so it would be better to package the older version
 with appropriate changes added as patches per-commit or a single patch).

Then just take commit 27 and 28, as suggested in my original bug report mail:

http://trac.edgewall.org/changeset?reponame=mercurial-pluginold=26@tracextnew=28@tracext


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



Bug#775746: [Python-modules-team] Bug#775746: python-genshi: Bug in Genshi i18n.py prevents uploading attachments in Trac

2015-01-20 Thread Johannes Weißl
On Tue, Jan 20, 2015 at 03:26PM -0500, Barry Warsaw wrote:
 It's not clear to me that such an exception would be granted in this case:
 
 https://release.debian.org/jessie/freeze_policy.html

You are right, it might not be a critical, grave, or serious bug,
because it does not render the whole package unusable.

But the current status is that the Trac issue tracking system in Debian
Jessie is not unusable if you have Trac users that want a non-English
(or at least German) user interface, which is quite sad. Adding
attachments to tickets is important.

Wish I would have tested this before 5th of December.

Regards,
Johannes


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



Bug#775785: trac-mercurial 1.0.0.4

2015-01-19 Thread Johannes Weißl
An alternative would be to directly package version 1.0.0.4 (c91c42e),
which contains a few more compatibility fixes for mercurial 3.x (for
bugs which I didn't encounter, but other users have):

http://trac.edgewall.org/wiki/TracMercurial#Releases

But I don't know if this is allowed during by the freeze policy.


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



Bug#775746: python-genshi: Bug in Genshi i18n.py prevents uploading attachments in Trac

2015-01-19 Thread Johannes Weißl
Package: python-genshi
Version: 0.7-3
Severity: important
Tags: upstream

Dear Maintainer,

A bug in Genshi prevents uploading attachments in Trac for users with non-
English language settings (IndexError: pop from empty list). The tickets in
Trac and Genshi are:
- http://trac.edgewall.org/ticket/11184
- http://genshi.edgewall.org/ticket/566

Since this bug greatly affects the usability of the trac package in Debian
Jessie, would you consider to apply the patch from upstream? This is the
commit:

http://genshi.edgewall.org/changeset/1243?format=diffnew=1243

I tested the patch in our production environment and confirmed that it works
and solves the bug.

Regards,
Johannes Weißl



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

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

Versions of packages python-genshi depends on:
ii  libc6   2.19-13
ii  python  2.7.8-2
pn  python:any  none

python-genshi recommends no packages.

Versions of packages python-genshi suggests:
pn  doc-base  none
pn  python-genshi-doc none
ii  python-pkg-resources  5.5.1-1

-- no debconf information


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



Bug#775785: trac-mercurial: Internal error when viewing Trac source browser

2015-01-19 Thread Johannes Weißl
Package: trac-mercurial
Version: 1.0.0.3+hg8df754d9b36a-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

The trac-mercurial plugin does not work with the current version of mercurial
in Jessie (3.1.2-2). Any attempt to view a specific file or the source browser
overview results in the following internal error:

AttributeError: 'localrepository' object has no attribute 'branchtags'

(the branchtags method has been removed in mercurial 2.9). It is possible to
view specific changesets, but not files or directories, which renders the
plugin unusable in my opinion.

The bug has been reported almost a year ago on the mailing list:
https://groups.google.com/d/msg/trac-dev/UQkkXs4Jiu8/0FfNuo2MqgkJ

Since this bug greatly affects the usability of the trac-mercurial package in
Debian Jessie, would you consider to apply the patch from upstream? It has been
fixed by commits 27 and 28:

http://trac.edgewall.org/changeset?reponame=mercurial-
pluginold=26%40tracextnew=28%40tracext

I tested the patch in our production environment and confirmed that it works
and solves the bug.

Regards,
Johannes Weißl



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

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

Versions of packages trac-mercurial depends on:
ii  mercurial  3.1.2-2
ii  python 2.7.8-2
ii  trac   1.0.2+dfsg-2

trac-mercurial recommends no packages.

trac-mercurial suggests no packages.

-- no debconf information


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



Bug#635494: cmus: new upstream version 2.4.2

2011-07-26 Thread Johannes Weißl
Package: cmus
Version: 2.4.1-2
Severity: wishlist

New upstream version 2.4.2 is available, which includes the patch!



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (400, 'testing'), (300, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages cmus depends on:
ii  libao4  1.1.0-1  Cross Platform Audio Output Librar
ii  libasound2  1.0.24.1-2   shared library for ALSA applicatio
ii  libc6   2.11.2-13Embedded GNU C Library: Shared lib
ii  libfaad22.7-6freeware Advanced Audio Decoder - 
ii  libflac81.2.1-4  Free Lossless Audio Codec - runtim
ii  libmad0 0.15.1b-6MPEG audio decoder library
ii  libmodplug1 1:0.8.8.2-3  shared libraries for mod music bas
ii  libmpcdec6  2:0.1~r459-1 MusePack decoder - library
ii  libncursesw55.9-1shared libraries for terminal hand
ii  libvorbisfile3  1.3.2-1  The Vorbis General Audio Compressi
ii  libwavpack1 4.60.1-1 an audio codec (lossy and lossless

Versions of packages cmus recommends:
ii  cmus-plugin-ffmpeg   2.4.2-1.1   lightweight ncurses audio player (
ii  libpulse00.9.23-1.1  PulseAudio client libraries
ii  libroar1 0.4~beta7-1 foundation libraries for the RoarA

cmus suggests no packages.

-- no debconf information



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



Bug#597160: cmus: volume set to 100%

2011-02-10 Thread Johannes Weißl
Hello Jonas,

On Sat, Sep 18, 2010 at 01:35:53AM +0200, Jonas Pfenninger wrote:
  Do I understand correctly that cmus sets the volume of system-wide
  mixer to 100% on both startup and shutdown?
 
 I will try to be elaborate: I'm using pavucontrol now to set the volume.
 There are two bars in pavucontrol, one for master volume and one for cmus
 volume (this one appears only when cmus is running and a song was played).
 I set both bars to some middle value. I exit cmus and start it again. Now 
 cmus shows
 volume 100% however master volume is still on 50%. Now I play a song and I
 can see how master volume in pavucontrol is also being set to 100%. I'm pretty
 sure that cmus-volume was set to 100% during the last exit of cmus, because
 I can hear it go up very briefly before the program exits.
 
 summary: cmus-volume goes up on exit, master goes up on first playing of a
 song.
 
 Also, I realize now that the behaviour of the two bars is not influenced 
 by the setting softvol. Only the value of the software controlled volume is
 saved, but the two bars in pavucontrol go up just as without softvol.

The bug has been fixed in cmus v2.3.4 [1].

[1] http://cmus.sourceforge.net/#download


Johannes


pgpFZccy0hOAr.pgp
Description: PGP signature


Bug#599369: python-pycountry: warning when importing

2010-10-06 Thread Johannes Weißl
Package: python-pycountry
Version: 0.12.1+ds1-1
Severity: minor
Tags: upstream patch

When importing, the following warning is produced:

No handlers could be found for logger pycountry.db

Attached is a patch which fixes this according to
http://docs.python.org/library/logging.html#configuring-logging-for-a-library



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

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

Versions of packages python-pycountry depends on:
ii  iso-codes 3.21-1 ISO language, territory, currency,
ii  python2.6.6-3interactive high-level object-orie
ii  python-support1.0.10 automated rebuilding support for P

python-pycountry recommends no packages.

python-pycountry suggests no packages.

-- no debconf information
diff -Naur pycountry-0.12.1+ds1.old/src/pycountry/db.py pycountry-0.12.1+ds1.new/src/pycountry/db.py
--- pycountry-0.12.1+ds1.old/src/pycountry/db.py	2010-04-21 07:44:11.0 +0200
+++ pycountry-0.12.1+ds1.new/src/pycountry/db.py	2010-10-07 00:05:09.784425001 +0200
@@ -7,7 +7,17 @@
 import logging
 import lxml.etree
 
+# NullHandler is only defined for python = 2.7
+if 'NullHandler' not in dir(logging):
+class NullHandler(logging.Handler):
+def emit(self, record):
+pass
+logging.NullHandler = NullHandler
+
 logger = logging.getLogger('pycountry.db')
+# Prevent warning, see
+# http://docs.python.org/library/logging.html#configuring-logging-for-a-library
+logger.addHandler(logging.NullHandler())
 
 
 class Data(object):


pgpRgEVC1l2dz.pgp
Description: PGP signature


Bug#577645: add patch to debian package

2010-09-22 Thread Johannes Weißl
I know, because I wrote the patch in the upstream bug report... still no
reaction there. Could we just add the patch to the Debian package until
it is accepted upstream?


pgpE1y4PVMV9V.pgp
Description: PGP signature


Bug#577645: libao4: libao crashes when using pulse plugin

2010-04-13 Thread Johannes Weißl
Package: libao4
Version: 1.0.0-4
Severity: important
Tags: upstream

libao crashes for some applications when pulse plugin is used. Bug report in
upstream: https://trac.xiph.org/ticket/1689


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.33.1 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libao4 depends on:
ii  libao-common  1.0.0-4Cross Platform Audio Output Librar
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib

libao4 recommends no packages.

Versions of packages libao4 suggests:
ii  libasound21.0.22-2   shared library for ALSA applicatio
ii  libaudio2 1.9.2-3Network Audio System - shared libr
ii  libesd0   0.2.41-7   Enlightened Sound Daemon - Shared 
ii  libpulse0 0.9.21-1.2 PulseAudio client libraries

-- no debconf information
Index: src/plugins/pulse/ao_pulse.c
===
--- src/plugins/pulse/ao_pulse.c	(revision 17144)
+++ src/plugins/pulse/ao_pulse.c	(working copy)
@@ -227,7 +227,7 @@
 }
 
 
-if (!(internal-simple = pa_simple_new(internal-server, fn ? t : libao, PA_STREAM_PLAYBACK, internal-sink, fn ? t2 : libao playback stream, ss, map, NULL, NULL)))
+if (!(internal-simple = pa_simple_new(internal-server, fn ? t : libao, PA_STREAM_PLAYBACK, internal-sink, fn ? t2 : libao playback stream, ss, device-input_map ? map : NULL, NULL, NULL)))
 return 0;
 
 device-driver_byte_format = AO_FMT_NATIVE;
@@ -247,9 +247,11 @@
 assert(device  device-internal);
 ao_pulse_internal *internal = (ao_pulse_internal *) device-internal;
 
-pa_simple_drain(internal-simple, NULL);
-pa_simple_free(internal-simple);
-internal-simple = NULL;
+if (internal-simple) {
+pa_simple_drain(internal-simple, NULL);
+pa_simple_free(internal-simple);
+internal-simple = NULL;
+}
 
 return 1;
 }


Bug#573171: lighttpd: $HTTP[url] contains full URI when using GET https in lenny

2010-03-09 Thread Johannes Weißl
Package: lighttpd
Version: 1.4.19-5+lenny1
Severity: important


$HTTP[url] contains full URI (https://host:443/somefile) when using an
https request like this:

GET https://host:443/somefile HTTP/1.1
Host: host:443

while it should only contain /somefile. It works if a relative path
for GET is used or in unencrypted http.

It works in squeeze, so the bug is fixed somewhere between
1.4.19-5+lenny1 and 1.4.26. It is important because it breaks all
$HTTP[url] =~ ^... checks in the config.

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

Kernel: Linux 2.6.31.5-vs2.3.0.36.21-beng (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lighttpd depends on:
ii  libattr1   1:2.4.43-2Extended attribute shared library
ii  libbz2-1.0 1.0.5-1   high-quality block-sorting file co
ii  libc6  2.7-18lenny2  GNU C Library: Shared libraries
ii  libfam02.7.0-13.3+lenny1 Client library to control the FAM 
ii  libldap-2.4-2  2.4.11-1+lenny1   OpenLDAP libraries
ii  libpcre3   7.6-2.1   Perl 5 Compatible Regular Expressi
ii  libssl0.9.80.9.8g-15+lenny6  SSL shared libraries
ii  libterm-readline-perl- 1.0302-1  Perl implementation of Readline li
ii  lsb-base   3.2-20Linux Standard Base 3.2 init scrip
ii  mime-support   3.44-1MIME files 'mime.types'  'mailcap
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

lighttpd recommends no packages.

Versions of packages lighttpd suggests:
ii  apache2-utils   2.2.9-10+lenny6  utility programs for webservers
ii  openssl 0.9.8g-15+lenny6 Secure Socket Layer (SSL) binary a
ii  rrdtool 1.3.1-4  Time-series data storage and displ

-- no debconf information



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



Bug#366745: caff has problems with UTF-8

2006-05-14 Thread Johannes Weißl
On 2006-05-14 17:41:58, Peter Palfrader wrote:
 How does encode_qp or Encode::encode() for that matter know which
 charset caffrc is in?

It seems newer versions of perl use UTF-8 for source files / strings
(and not the system encoding).
If someone wants caffrc to be encoded in e.g. Latin1, he has to write
use encoding latin-1;
at the beginning of ~/.caffrc.

At least that's what I think ...

-- 
Johannes Weißl


pgpvVazyVVtHg.pgp
Description: PGP signature


Bug#366745: caff has problems with UTF-8

2006-05-10 Thread Johannes Weißl
Package: signing-party
Version: 0.4.6-1
Severity: normal

It seems caff has a problem with non-ASCII characters:
When I set $CONFIG{'owner'} in ~/.caffrc to e.g. 'Johannes Weißl',
I get the following error from debian.org addresses:

Diagnostic-Code: X-Postfix; host master.debian.org[146.82.138.7] said: 550
improper use of 8-bit data in message header (in reply to end of DATA 
command)

And in messages from other caff-users the uid in the message body is
displayed as Johannes Wei?\x9fl.

I wrote a patch that addresses the header-problem:
It encodes the owner in quoted-printable (it's a hack, and I didn't read
through RFC 2047).

The other problem is maybe because the information is gained from the
output of gpg (locale problem?!).


perl-version: v5.8.7
`locale charmap`: UTF-8
`file ~/.caffrc`: UTF-8 Unicode English text


-- 
Johannes Weißl
--- caff.org2006-05-09 23:27:24.0 +0200
+++ caff2006-05-10 20:19:11.0 +0200
@@ -297,6 +297,7 @@
 use File::Temp qw{tempdir};
 use Text::Template;
 use MIME::Entity;
+use Encode;
 use Fcntl;
 use IO::Select;
 use Getopt::Long;
@@ -335,6 +336,14 @@
 };
 
 
+sub encode_qp($) {
+my @words;
+foreach (split(/ /, shift)) {
+push(@words, Encode::encode('MIME-Q', $_));
+}
+return join( , @words);
+};
+
 sub generate_config() {
notice(Error: \$LOGNAME is not set.\n) unless defined $ENV{'LOGNAME'};
my $gecos = defined $ENV{'LOGNAME'} ? (getpwnam($ENV{LOGNAME}))[6] : 
undef;
@@ -799,7 +808,7 @@
 
$message_entity-head-add(Subject, Your signed PGP key 0x$key_id);
$message_entity-head-add(To, $address);
-   $message_entity-head-add(From, ''.$CONFIG{'owner'}.' 
'.$CONFIG{'email'}.'');
+   $message_entity-head-add(From, ''.encode_qp($CONFIG{'owner'}).' 
'.$CONFIG{'email'}.'');
$message_entity-head-add(Reply-To, $CONFIG{'reply-to'}) if defined 
$CONFIG{'reply-to'};
$message_entity-head-add(Bcc, $CONFIG{'bcc'}) if defined 
$CONFIG{'bcc'};
$message_entity-head-add(User-Agent, $USER_AGENT);


pgpa8U5BFV8kG.pgp
Description: PGP signature