Bug#947425: incron crashes in IncronTabEntry::GetSafePath due to use-after-free bug

[Willi Mann]

Package: incron
Version: 0.5.12-1
Severity: grave
Tags: security patch upstream

Hi,

incron crashes for me frequently. As incron runs as root, but is controllable
by users, this bug might be security-relevant, so I'm reporting it a severity
grave and tagging it security.  Please downgrade if you can rule out this
concern.

Further investigation shows that the problem is caused by the creation of new
directories within watched paths: these trigger a reload of the inotify watch
target, rendering the old watch structure invalid. Only after the reload,
potential commands are executed. This may require to get path of the event, but
the corresponding pointer is invalid after the reload.

Attached is a patch that extracts the path before the reload, making this
problem disappear for me. Note that the patch assumes that LOOPER is not
defined, which seems to be the case for the Debian package.

Backtrace for reference:

bt full
#0  0x004ba484 in IncronTabEntry::GetSafePath (rPath=) at /usr/include/c++/8/bits/basic_string.h:1046
i = 0
stream = 
len = 1919509615
#1  0x004c43f3 in UserTable::OnEvent (this=, rEvt=...) at 
inotify-cxx.h:428
px = 40
pW = 0x1fbde40
pE = 0x1fbc920
events = "IN_CREATE,IN_ISDIR"
cmd = "/home/user/autoscripts/imageresize.sh "
cs = "/home/user/autoscripts/imageresize.sh $@/$# $# $%"
pos = 39
oldpos = 0
len = 
pid = 
#2  0x004c4767 in EventDispatcher::ProcessEvents (this=) at 
usertable.cpp:110
pIn = 0x1fc7d24
it = {first = 1702521203, second = 0x1fc0072}
i = 2
pipe = false
evt = {m_uMask = 1073742080, m_uCookie = 0, m_name = "Neuer Ordner", 
m_pWatch = 0x1fbde40}
#3  0x004b8650 in main (argc=, argv=) at 
icd-main.cpp:458
res = 
wm = 10184
in = {m_fd = 6, m_watches = std::map with 2 elements = {[1] = 
0xbfc8ab40, [2] = 0xbfc8ab68}, m_paths = std::map with 2 elements = {
["/etc/incron.d"] = 0xbfc8ab40, ["/var/spool/incron"] = 
0xbfc8ab68}, m_buf = '\000' ..., m_events = std::deque 
with 0 elements}
stw = {m_path = "/etc/incron.d", m_uMask = 10184, m_wd = 1, m_pInotify 
= 0xbfc8ab90, m_fEnabled = true}
utw = {m_path = "/var/spool/incron", m_uMask = 10184, m_wd = 2, 
m_pInotify = 0xbfc8ab90, m_fEnabled = true}
ed = {m_iPipeFd = 4, m_iMgmtFd = 6, m_pIn = 0xbfc8ab90, m_pSys = 
0xbfc8ab40, m_pUser = 0xbfc8ab68, m_maps = std::map with 1 element = {[8] = 
0x1fc7d20}, 
  m_size = 3, m_pPoll = 0x1fbe080}
cfg = "/etc/incron.conf"
lckdir = "/var/run"
lckfile = "incrond"
app = {m_path = "/var/run/incrond.pid", m_fLocked = true}
ret = 0
sysBase = "/etc/incron.d"
userBase = "/var/spool/incron"

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages incron depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libstdc++6   8.3.0-6
ii  lsb-base 10.2019051400

incron recommends no packages.

incron suggests no packages.

-- Configuration Files:
/etc/incron.allow [Errno 13] Keine Berechtigung: '/etc/incron.allow'
/etc/incron.deny [Errno 13] Keine Berechtigung: '/etc/incron.deny'

-- no debconf information
diff --git a/usertable.cpp b/usertable.cpp
index 3f1ef4a..bdc7f29 100644
--- a/usertable.cpp
+++ b/usertable.cpp
@@ -370,6 +370,8 @@ void UserTable::OnEvent(InotifyEvent& rEvt)
 {
   InotifyWatch* pW = rEvt.GetWatch();
   IncronTabEntry* pE = FindEntry(pW);
+
+  std::string pWPath = pW->GetPath();
 
   // no entry found - this shouldn't occur
   if (pE == NULL)
@@ -422,7 +424,7 @@ void UserTable::OnEvent(InotifyEvent& rEvt)
   else {
 cmd.append(cs.substr(oldpos, pos-oldpos));
 if (cs[px] == '@') {  // base path
-  cmd.append(IncronTabEntry::GetSafePath(pW->GetPath()));
+  cmd.append(IncronTabEntry::GetSafePath(pWPath));
   oldpos = pos + 2;
 }
 else if (cs[px] == '#') { // file name

Bug#921198: testing also affected

[Willi Mann]

Hi,

as the problem is not new, I've marked the version in testing as
affected and I changed the title of the bug accordingly.

Willi

Bug#921198: hard to track down

[Willi Mann]

Hi,

just for the record, I tried to reproduce the build failure on eller
(mipsel porterbox), but it builds fine there. I'm wondering whether the
timeout set on line 232 of tests/srp.c (40 seconds) is too short for
slower build hosts.

Willi

Bug#816570: fix uploaded to DELAYED

[Willi Mann]

Hi,

I uploaded a fix for this bug to DELAYED/10. debdiff attached.

Willi
diff -Nru mrtrix-0.2.12/debian/changelog mrtrix-0.2.12/debian/changelog
--- mrtrix-0.2.12/debian/changelog	2015-12-29 18:21:14.0 +0100
+++ mrtrix-0.2.12/debian/changelog	2017-10-21 16:22:07.0 +0200
@@ -1,3 +1,10 @@
+mrtrix (0.2.12-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build error with ambigous call to round (closes: #816570)
+
+ -- Willi Mann <wi...@debian.org>  Sat, 21 Oct 2017 16:22:07 +0200
+
 mrtrix (0.2.12-2) unstable; urgency=medium
 
   * Add patch to include  to fix FTBFS due to missing size_t.
diff -Nru mrtrix-0.2.12/debian/patches/fix-build-error-round mrtrix-0.2.12/debian/patches/fix-build-error-round
--- mrtrix-0.2.12/debian/patches/fix-build-error-round	1970-01-01 01:00:00.0 +0100
+++ mrtrix-0.2.12/debian/patches/fix-build-error-round	2017-10-21 16:22:03.0 +0200
@@ -0,0 +1,17 @@
+Index: mrtrix-0.2.12/cmd/tracks2prob.cpp
+===
+--- mrtrix-0.2.12.orig/cmd/tracks2prob.cpp
 mrtrix-0.2.12/cmd/tracks2prob.cpp
+@@ -127,9 +127,9 @@ class Voxel
+   z (_z_) { }
+ 
+ Voxel (const Point& p) :
+-  x (round (p[0])),
+-  y (round (p[1])),
+-  z (round (p[2]))
++  x (MR::round (p[0])),
++  y (MR::round (p[1])),
++  z (MR::round (p[2]))
+ { 
+   assert (gsl_finite (p[0]) && gsl_finite (p[1]) && gsl_finite (p[2]));
+ }
diff -Nru mrtrix-0.2.12/debian/patches/series mrtrix-0.2.12/debian/patches/series
--- mrtrix-0.2.12/debian/patches/series	2015-12-29 17:17:10.0 +0100
+++ mrtrix-0.2.12/debian/patches/series	2017-10-21 16:20:03.0 +0200
@@ -1,3 +1,4 @@
 debian_build_cfg
 glib-single-include.patch
 size_t-ftbfs
+fix-build-error-round

Bug#875696: patch

[Willi Mann]

Control: tag -1 + patch

Hi,

attached is a patch that fixes the problem with the @piddir@. Note
however, that by default, the LISTS variable in the config file is
empty. As long as LISTS is empty, the webmlm will still not start.

Bye
Willi
Index: courier-0.76.3/courier/configure.ac
===
--- courier-0.76.3.orig/courier/configure.ac
+++ courier-0.76.3/courier/configure.ac
@@ -112,6 +112,9 @@ AC_ARG_WITH(transport,
 
 AC_SUBST(transport)
 
+AC_ARG_WITH(piddir, [  --with-piddir Directory where PID files are located ], piddir="$withval", piddir=/var/run)
+AC_SUBST(piddir)
+
 AC_MSG_CHECKING(for modules to compile)
 
 dirlist=""

Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi,

Am 2016-12-28 um 10:09 schrieb Klaus Ethgen:
> Package: logwatch
> Version: 7.4.3+git20161207-1
> Severity: critical
> 
> Current logwatch did change from sending mails with charset iso-8859-1
> to UTF-8. This openes up a potential security hole as UTF-8 is not able
> to display all 8bit data.

in order to fix this bug for stretch (next Debian stable release), I
will upload a version of logwatch that reverts the change from
iso-8859-1 to utf-8 for mails sent by logwatch. This is not my preferred
way to fix this issue, but any better fix I can imagine will require
some new configuration options, which I don't want to introduce in
Debian before they are committed upstream.

Bye
Willi

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi Klaus,

Am 2017-01-15 um 17:43 schrieb Klaus Ethgen:
> Hi Willi,
> 
> Am Sa den 14. Jan 2017 um 16:43 schrieb Willi Mann:
>> in order to come closer to a fix for this issue, I propose the following
>> two patches:
> 
> 
>> 0001-Add-outputencoding-parameter.patch
> 
>> This patch allows to configure the value for the charset in the
>> Content-Type line in mail output. This should address Klaus Ethgen's
>> original concern.
> 
> Well, partly. It will, in fact, let me configure it the way, that it
> solves my issue.
> 
> However, It does not fix the issue itself as it does not ensure that the
> output in mail is that charset. As I mentioned before, this is exactly
> the issue. The mail could be easily in UTF-8. But then there has to be
> logic to keep sure that the mail is in that charset. Without, you could
> still end with logical incorrect mails that are (partly) in different
> charsets that is illegal for UTF-8.

I understand that the illegal UTF-8 is bad. But I have to admit that I'm
not yet sure why it is bad in terms of security, especially since we are
talking about mail - and anyone could send you an e-mail with illegal
UTF-8 sequences.

>> Since most people use UTF-8, I left the default at UTF-8.
> 
> No objection about that. But you cannot be sure that log stuff is in the
> same charset.

Yeah, that I'm aware of.

>> 0002-Use-pager-on-stdout-output-to-terminal.patch
> [...]
>> Let me know what you think about these patches.
> 
> Patches looks good for me for fixing the bug partly. Nevertheless I
> would expect some use of iconv for really ensure the choosed charset.
> Maybe even encguess can come to use for guessing the input.

Does anybody have a good idea on how to implement this? Concerning the
second part (guessing the input encoding), I'm not really sure at
what point logwatch should try to guess and assume a particular charset.
Especially for the first part, does anybody know some example code?
Maybe some other project that had to solve the same issue in Perl?

Willi

Bug#849531: [Logwatch-devel] Bug#849531: Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi,

Am 2017-01-14 um 16:48 schrieb Mike Tremaine:
> 
>> 0002-Use-pager-on-stdout-output-to-terminal.patch
>>
>> Use pager less if output is on terminal. This should address the issues
>> associated with escape sequences in logs that may mess with your
>> terminal. Less seems to be good at filtering these escape sequences.
> 
> 
> Sounds good, but I’d make it a config switch and leave the default as is. 
> Some “lazy” destro's let cron handle terminal output to mail directly… :/ 

But, then "-t STDOUT" is false (see patch) - in this case, the pager
will not be invoked. I also made the pager configurable and it can be
set to am empty string to disable). I updated the help text in the
second patch to document that better.

Willi
>From 162f8b2e7fae134e65761dc64e0a8d29c9c172d4 Mon Sep 17 00:00:00 2001
From: Willi Mann <wi...@wm1.at>
Date: Sat, 14 Jan 2017 15:32:39 +0100
Subject: [PATCH 1/2] Add outputencoding parameter

---
 conf/logwatch.conf  | 8 
 scripts/logwatch.pl | 8 +---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/conf/logwatch.conf b/conf/logwatch.conf
index 2b61ec6..0d0e31b 100644
--- a/conf/logwatch.conf
+++ b/conf/logwatch.conf
@@ -126,4 +126,12 @@ mailer = "/usr/sbin/sendmail -t"
 #
 #HostLimit = myhost
 
+#
+# With this option, the output encoding for mail headers can be set. It
+# defaults to utf-8. Be aware that the default value may change to autodetect
+# (take the system's encoding). Note that the configured value will be
+# upper-cased.
+#
+# OutputEncoding = utf-8
+
 # vi: shiftwidth=3 tabstop=3 et
diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0167755..0cff511 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -90,6 +90,7 @@ $Config{'pathtobzcat'} = "bzcat";
 $Config{'output'} = "stdout"; #8.0
 $Config{'format'} = "text"; #8.0
 $Config{'encode'} = "none"; #8.0
+$Config{'outputencoding'} = "utf-8";
 $Config{'hostformat'} = "none"; #8.0
 $Config{'html_wrap'} = 80;
 $Config{'supress_ignores'} = 0;
@@ -1160,11 +1161,12 @@ sub initprint {
  } else {
 $out_mime .= "Content-Transfer-Encoding: 7bit\n";
  }
- #Config{output} html
+ #Config{output} html, Config{outputenconding}
+ my $encoding = uc($Config{outputencoding});
  if ( $Config{'format'} eq "html" ) {
-$out_mime .= "Content-Type: text/html; charset=\"UTF-8\"\n\n";
+$out_mime .= "Content-Type: text/html; charset=\"$encoding\"\n\n";
  } else {
-$out_mime .= "Content-Type: text/plain; charset=\"UTF-8\"\n\n";
+$out_mime .= "Content-Type: text/plain; charset=\"$encoding\"\n\n";
  }
 
  if ($Config{'hostformat'} eq "split") { #8.0 check hostlimit also? or ne none?
-- 
2.1.4

>From 0f52b6b4a35e8aa33d2827f90d515491c15a3d41 Mon Sep 17 00:00:00 2001
From: Willi Mann <wi...@wm1.at>
Date: Sat, 14 Jan 2017 16:25:30 +0100
Subject: [PATCH 2/2] Use pager on stdout output to terminal

---
 conf/logwatch.conf  | 5 +
 scripts/logwatch.pl | 7 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/conf/logwatch.conf b/conf/logwatch.conf
index 0d0e31b..c46b5d6 100644
--- a/conf/logwatch.conf
+++ b/conf/logwatch.conf
@@ -134,4 +134,9 @@ mailer = "/usr/sbin/sendmail -t"
 #
 # OutputEncoding = utf-8
 
+#
+# For output type stdout, logwatch uses the pager Pager if STDOUT is a terminal.
+# Am empty string disables the pager.
+#Pager = /usr/bin/less
+
 # vi: shiftwidth=3 tabstop=3 et
diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0cff511..f053cb3 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -88,6 +88,7 @@ $Config{'pathtocat'} = "cat";
 $Config{'pathtozcat'} = "zcat";
 $Config{'pathtobzcat'} = "bzcat";
 $Config{'output'} = "stdout"; #8.0
+$Config{'pager'} = "/usr/bin/less"; #8.0
 $Config{'format'} = "text"; #8.0
 $Config{'encode'} = "none"; #8.0
 $Config{'outputencoding'} = "utf-8";
@@ -1127,7 +1128,11 @@ sub initprint {
$OStitle = "Solaris" if ($OSname eq "SunOS" && $release >= 2);
 
if ($Config{'output'} eq "stdout") { #8.0 start with others?
-  *OUTFILE = *STDOUT;
+  if($Config{'pager'} and -t STDOUT) {
+ open(OUTFILE,"|$Config{'pager'}") or die "could not open pager: $Config{'pager'} $!";
+  } else {
+ *OUTFILE = *STDOUT;
+  }
} elsif ($Config{'output'} eq "file") {
   open(OUTFILE,">>" . $Config{'filename'}) or die "Can't open output file: $Config{'filename'} $!\n";
} else {
-- 
2.1.4

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi,

in order to come closer to a fix for this issue, I propose the following
two patches:


0001-Add-outputencoding-parameter.patch

This patch allows to configure the value for the charset in the
Content-Type line in mail output. This should address Klaus Ethgen's
original concern. Since most people use UTF-8, I left the default at UTF-8.

0002-Use-pager-on-stdout-output-to-terminal.patch

Use pager less if output is on terminal. This should address the issues
associated with escape sequences in logs that may mess with your
terminal. Less seems to be good at filtering these escape sequences.


Let me know what you think about these patches.

Willi

Am 2017-01-01 um 23:01 schrieb Mike Tremaine:
> 
>>
>> The fail-safe default before was ISO-8859-1. So I suggest to use it
>> again.
>>
> 
> 
> If stream converted output it s require please consider making it a 
> configurable module in the code base that can be turned on and off and 
> modified (the module) as needed. Leave the default as is, that way DESTRO’s 
> and users can configure to their liking. But it will work as intended all the 
> way back to the stone-age tools that we started this project with. (I’m 
> looking at you Solaris 7/8)
> 
> 
> -Mike
> 

>From 162f8b2e7fae134e65761dc64e0a8d29c9c172d4 Mon Sep 17 00:00:00 2001
From: Willi Mann <wi...@wm1.at>
Date: Sat, 14 Jan 2017 15:32:39 +0100
Subject: [PATCH 1/2] Add outputencoding parameter

---
 conf/logwatch.conf  | 8 
 scripts/logwatch.pl | 8 +---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/conf/logwatch.conf b/conf/logwatch.conf
index 2b61ec6..0d0e31b 100644
--- a/conf/logwatch.conf
+++ b/conf/logwatch.conf
@@ -126,4 +126,12 @@ mailer = "/usr/sbin/sendmail -t"
 #
 #HostLimit = myhost
 
+#
+# With this option, the output encoding for mail headers can be set. It
+# defaults to utf-8. Be aware that the default value may change to autodetect
+# (take the system's encoding). Note that the configured value will be
+# upper-cased.
+#
+# OutputEncoding = utf-8
+
 # vi: shiftwidth=3 tabstop=3 et
diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0167755..0cff511 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -90,6 +90,7 @@ $Config{'pathtobzcat'} = "bzcat";
 $Config{'output'} = "stdout"; #8.0
 $Config{'format'} = "text"; #8.0
 $Config{'encode'} = "none"; #8.0
+$Config{'outputencoding'} = "utf-8";
 $Config{'hostformat'} = "none"; #8.0
 $Config{'html_wrap'} = 80;
 $Config{'supress_ignores'} = 0;
@@ -1160,11 +1161,12 @@ sub initprint {
  } else {
 $out_mime .= "Content-Transfer-Encoding: 7bit\n";
  }
- #Config{output} html
+ #Config{output} html, Config{outputenconding}
+ my $encoding = uc($Config{outputencoding});
  if ( $Config{'format'} eq "html" ) {
-$out_mime .= "Content-Type: text/html; charset=\"UTF-8\"\n\n";
+$out_mime .= "Content-Type: text/html; charset=\"$encoding\"\n\n";
  } else {
-$out_mime .= "Content-Type: text/plain; charset=\"UTF-8\"\n\n";
+$out_mime .= "Content-Type: text/plain; charset=\"$encoding\"\n\n";
  }
 
  if ($Config{'hostformat'} eq "split") { #8.0 check hostlimit also? or ne none?
-- 
2.1.4

>From 4e2579f41f1b94db97d265a72f67309cbf1737fa Mon Sep 17 00:00:00 2001
From: Willi Mann <wi...@wm1.at>
Date: Sat, 14 Jan 2017 16:25:30 +0100
Subject: [PATCH 2/2] Use pager on stdout output to terminal

---
 conf/logwatch.conf  | 4 
 scripts/logwatch.pl | 7 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/conf/logwatch.conf b/conf/logwatch.conf
index 0d0e31b..e15ed3b 100644
--- a/conf/logwatch.conf
+++ b/conf/logwatch.conf
@@ -134,4 +134,8 @@ mailer = "/usr/sbin/sendmail -t"
 #
 # OutputEncoding = utf-8
 
+#
+# For output type stdout, use pager if the stdout is a terminal.
+#Pager = /usr/bin/less
+
 # vi: shiftwidth=3 tabstop=3 et
diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0cff511..f053cb3 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -88,6 +88,7 @@ $Config{'pathtocat'} = "cat";
 $Config{'pathtozcat'} = "zcat";
 $Config{'pathtobzcat'} = "bzcat";
 $Config{'output'} = "stdout"; #8.0
+$Config{'pager'} = "/usr/bin/less"; #8.0
 $Config{'format'} = "text"; #8.0
 $Config{'encode'} = "none"; #8.0
 $Config{'outputencoding'} = "utf-8";
@@ -1127,7 +1128,11 @@ sub initprint {
$OStitle = "Solaris" if ($OSname eq "SunOS" && $release >= 2);
 
if ($Config{'output'} eq "stdout") { #8.0 start with others?
-  *OUTFILE = *STDOUT;
+  if($Config{'pager'} and -t STDOUT) {
+ open(OUTFILE,"|$Config{'pager'}") or die "could not open pager: $Config{'pager'} $!";
+  } else {
+ *OUTFILE = *STDOUT;
+  }
} elsif ($Config{'output'} eq "file") {
   open(OUTFILE,">>" . $Config{'filename'}) or die "Can't open output file: $Config{'filename'} $!\n";
} else {
-- 
2.1.4

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi,

Am 2017-01-01 um 00:20 schrieb Jason Pyeron:
> Not exactly a valid test, besides it works for me. The issue is internal 
> ascii data being written as ascii but instructing consumers
> it is uft8. 
> 
> $ cat utf8_test.pl
> #!/usr/bin/perl
> #
> use strict;
> use File::Slurp;
> 
> my $inputfile = @ARGV[0];
> my $logfilecontent = read_file($inputfile);
> binmode(STDOUT, ":utf8");
> print $logfilecontent;
> 
> $ ./utf8_test.pl testlog.txt
> übersät
> 
> $ ./utf8_test.pl testlog.txt | hexdump -C
>   c3 bc 62 65 72 73 c3 a4  74 0a|..bers..t.|
> 000a
> 
> $ hexdump.exe -C testlog.txt
>   fc 62 65 72 73 e4 74 0a   |.bers.t.|
> 0008

What do you want to say with that? Your input is not in UTF-8.

Just for the record, the output what I posted originally:

% ./utf8_test.pl testlog
übersät
% ./utf8_test.pl testlog | hexdump -C
  c3 83 c2 bc 62 65 72 73  c3 83 c2 a4 74 0a|berst.|
000e
% hexdump -C testlog
  c3 bc 62 65 72 73 c3 a4  74 0a|..bers..t.|
000a

Bye
Willi

Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Dear Security Team,

I would like to get your input on bug #849531 [1]. A short summary:

Logwatch is a log summarizer that parses various logfiles and reports a
summary, either via e-mail or to stdout. Parts of the input are copied
verbatim w.r.t. to their encoding to the output (e.g., usernames, URLs,
etc.)  However, e-mails were sent with a hard-coded Content-Type: ...
encoding=ISO-8859-1. This meant that non-ascii UTF-8 characters were not
displayed correctly.

As part of a recent change that is already in Debian testing/unstable,
the Content-Type line was modified to say that the encoding is UTF-8,
obviously to ensure that utf-8 characters are displayed correctly.
However, logwatch does not ensure that the output is correct utf-8, and
that is claimed to be a security problem.

So my question is: Is it a security issue if a script sends e-mails with
encoding=utf-8, but potentially containing invalid utf-8 strings? If
yes, what would be the (minimum) requirements to address this problem?

thank you for your time
Willi

[1] https://bugs.debian.org/849531

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi Jason,

thanks for your test cases. However, I don't think that binmode provides
an acceptable solution, at least not alone. While it ensures that the
strings are valid utf-8 strings, it will convert any valid utf-8
character to two "garbage" characters. Try

$ ./utf8_test.pl testlog

(see attached files)

I'm not really sure what a proper solution is. But I'm actually not yet
fully convinced that there is a problem logwatch should solve. I will
ask Debian's security team for advice.

WM



Am 2016-12-30 um 20:26 schrieb Jason Pyeron:
> A very rudimentary test:
> 
> /projects/logwatch
> $ perl -e 'for ($i=0; $i<256; ++$i) {print chr($i);}' | hexdump.exe -C
>   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  ||
> 0010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  ||
> 0020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
> 0030  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
> 0040  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
> 0050  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
> 0060  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
> 0070  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
> 0080  80 81 82 83 84 85 86 87  88 89 8a 8b 8c 8d 8e 8f  ||
> 0090  90 91 92 93 94 95 96 97  98 99 9a 9b 9c 9d 9e 9f  ||
> 00a0  a0 a1 a2 a3 a4 a5 a6 a7  a8 a9 aa ab ac ad ae af  ||
> 00b0  b0 b1 b2 b3 b4 b5 b6 b7  b8 b9 ba bb bc bd be bf  ||
> 00c0  c0 c1 c2 c3 c4 c5 c6 c7  c8 c9 ca cb cc cd ce cf  ||
> 00d0  d0 d1 d2 d3 d4 d5 d6 d7  d8 d9 da db dc dd de df  ||
> 00e0  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  ||
> 00f0  f0 f1 f2 f3 f4 f5 f6 f7  f8 f9 fa fb fc fd fe ff  ||
> 0100
> 
> /projects/logwatch
> $ perl -e 'binmode(STDOUT, ":utf8"); for ($i=0; $i<256; ++$i) {print STDOUT 
> chr($i);}' | hexdump.exe -C
>   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  ||
> 0010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  ||
> 0020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
> 0030  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
> 0040  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
> 0050  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
> 0060  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
> 0070  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
> 0080  c2 80 c2 81 c2 82 c2 83  c2 84 c2 85 c2 86 c2 87  ||
> 0090  c2 88 c2 89 c2 8a c2 8b  c2 8c c2 8d c2 8e c2 8f  ||
> 00a0  c2 90 c2 91 c2 92 c2 93  c2 94 c2 95 c2 96 c2 97  ||
> 00b0  c2 98 c2 99 c2 9a c2 9b  c2 9c c2 9d c2 9e c2 9f  ||
> 00c0  c2 a0 c2 a1 c2 a2 c2 a3  c2 a4 c2 a5 c2 a6 c2 a7  ||
> 00d0  c2 a8 c2 a9 c2 aa c2 ab  c2 ac c2 ad c2 ae c2 af  ||
> 00e0  c2 b0 c2 b1 c2 b2 c2 b3  c2 b4 c2 b5 c2 b6 c2 b7  ||
> 00f0  c2 b8 c2 b9 c2 ba c2 bb  c2 bc c2 bd c2 be c2 bf  ||
> 0100  c3 80 c3 81 c3 82 c3 83  c3 84 c3 85 c3 86 c3 87  ||
> 0110  c3 88 c3 89 c3 8a c3 8b  c3 8c c3 8d c3 8e c3 8f  ||
> 0120  c3 90 c3 91 c3 92 c3 93  c3 94 c3 95 c3 96 c3 97  ||
> 0130  c3 98 c3 99 c3 9a c3 9b  c3 9c c3 9d c3 9e c3 9f  ||
> 0140  c3 a0 c3 a1 c3 a2 c3 a3  c3 a4 c3 a5 c3 a6 c3 a7  ||
> 0150  c3 a8 c3 a9 c3 aa c3 ab  c3 ac c3 ad c3 ae c3 af  ||
> 0160  c3 b0 c3 b1 c3 b2 c3 b3  c3 b4 c3 b5 c3 b6 c3 b7  ||
> 0170  c3 b8 c3 b9 c3 ba c3 bb  c3 bc c3 bd c3 be c3 bf  ||
> 0180
>  
> This confirms that binmode utf8 is needed to print out the full ASCII range.
> 
>> -Original Message-
>> From: Jason Pyeron [mailto:jpye...@pdinc.us] 
>> Sent: Friday, December 30, 2016 14:03
>> To: Jason Pyeron; 'Willi Mann'; logwatch-de...@lists.sourceforge.net
>> Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org; 
>> 'Klaus Ethgen'
>> Subject: RE: [Logwatch-devel] Bug#849531: Possible security 
>> problem,new logwatch sends mails with charset UTF-8
>>
>> I have opened https://sourceforge.net/p/logwatch/bugs/56/ .
>>
>> I am working a test case for this right now.
>>
>> As I see it, there are 3 pa

Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi Klaus,

Am 2016-12-30 um 18:36 schrieb Klaus Ethgen:
> Hi Willi,
> 
> Am Fr den 30. Dez 2016 um 18:18 schrieb Willi Mann:
>> can you elaborate how this could be exploited?
> 
> Well, log principally contains untrusted data that could be injected
> from untrusted source. That is no security hole itself.
> 
> But when that data gets displayed with the wrong charset, that can
> trigger problems in window managers (for example). See xterm which can
> be controlled via ansii sequences. Even more, it could trigger stream
> conversion problems if the UTF-8 implementation is not really fully
> tested with broken streams.

OK, I understand that text from untrusted sources is dangerous and could
be harmful to your terminal - and that it is better to assume logfiles
to be such an untrusted source. However, the change only affects
mailers, right? For mailers, I would expect them to not trust any mails
they get, and therefore to remove any dangerous byte sequences.
Otherwise, the mailer contains the security hole - and an attacker does
not need to go via logfiles and logwatch, he just sends you mail.

When running logwatch such that it writes its output to the terminal,
the change does not have any effect on the security, right?. If there is
a security issue with untrusted data, it was already there before.

So far, I cannot see that the change you mentioned would be problematic.
What I do see is that it might be wise to sanitize the output of
logwatch. A possible way to go might be to remove any byte with value <
0x20 - unless it is a newline or tab. But that is independent of the
ISO-8859-15 to utf-8 change.

Bye
Willi

Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi Klaus,

can you elaborate how this could be exploited? What would be your
suggested fix?

I'm including the upstream mailing list in the conversation.

thanks you
Willi

Am 2016-12-28 um 10:09 schrieb Klaus Ethgen:
> Package: logwatch
> Version: 7.4.3+git20161207-1
> Severity: critical
> 
> Current logwatch did change from sending mails with charset iso-8859-1
> to UTF-8. This openes up a potential security hole as UTF-8 is not able
> to display all 8bit data.
> 
> This is especially true as the output from logwatch is from untrusted
> source where there could easily put some malicious content in. Logwatch
> does nothing to cleanup the mail content or convert it from the native
> charset to UTF-8.
> 
> Note that this bug went in recently as 7.4.0 did not have this bug
> (neither does 7.4.1). I do not find any upstream changelog in the
> package and when I download it from upstream directly, I cannot find any
> note of this breaking change.
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.7.10 (SMP w/8 CPU cores)
> Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages logwatch depends on:
> ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-2
> pn  perl:any   
> 
> Versions of packages logwatch recommends:
> ii  libdate-manip-perl   6.56-1
> ii  libsys-cpu-perl  0.61-2+b1
> pn  libsys-meminfo-perl  
> 
> Versions of packages logwatch suggests:
> ii  fortune-mod  1:1.99.1-7
> 
> -- no debconf information
> 
> 

Bug#800468: crashes in liblmdb on start-up

[Willi Mann]

Am 2015-10-03 um 19:42 schrieb Felix Geyer:
> Hi,
> 
> On Sat, 03 Oct 2015 15:58:34 +0200 Mario Blättermann 
>  wrote:
>> Same behavior on a freshly installed Stretch. The gdb output:
>>
>> (gdb) run
>> Starting program: /usr/bin/dolphin
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> [New Thread 0x7fffe235a700 (LWP 14801)]
>> [New Thread 0x7fffdafbd700 (LWP 14802)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x7fffead34960 in mdb_txn_begin ()
>> from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
>>
>> It happened after I tried to config Dolphin to let the preview sidebar 
>> appear.
> 
> Could you please test if upgrading libkf5baloo5 and libkf5balooengine5 to 
> 5.14.0-2 (unstable)
> fixes the crash?

Yes, upgrading these packages fixes the problem.

thanks
Willi

Bug#800468: crashes in liblmdb on start-up

[Willi Mann]

Package: dolphin
Version: 4:15.08.1-1
Severity: grave

Hi,

dolphin crashes on every attempt to start (i.e. it shows the window with the
directory content for a second and then segfaults) with the following
backtrace:

bt full
#0  mdb_txn_begin (env=0x0, parent=0x0, flags=131072, ret=0x7fffcd574788) at 
mdb.c:2650
txn = 
ntxn = 
rc = 
size = 
tsize = 136
#1  0x7f374b62ca1c in Baloo::File::load() () from 
/usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5
No symbol table info available.
#2  0x7f374bbc2cb6 in Baloo::FileFetchJob::doStart (this=0x277ce30) at 
../../src/filefetchjob.cpp:58
file = {d = 0x294f500}
comment = {static null = {}, d = 0x0}
prop = {d = 0x23b4500}
md = 
tags = { = { = {}, {p = {static shared_null = {ref = {atomic = {_q_value = -1}}, alloc = 
0, 
  begin = 0, end = 0, array = {0x0}}, d = 0x240a540}, d = 
0x240a540}}, }
rating = 
__for_range = 
#3  0x7f37488b41c1 in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#4  0x7f3749360b8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#5  0x7f3749366230 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#6  0x7f3748882a8b in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#7  0x7f3748884bc7 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#8  0x7f37488d73b2 in 
QEventDispatcherUNIX::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#9  0x7f373a05c8ed in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
No symbol table info available.
#10 0x7f37488802ca in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#11 0x7f3748887e3c in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#12 0x7f374db55294 in kdemain () from 
/usr/lib/x86_64-linux-gnu/libkdeinit5_dolphin.so
No symbol table info available.
#13 0x7f374d76fb45 in __libc_start_main (main=0x400730 , argc=1, 
argv=0x7fffcd575068, init=, fini=, 
rtld_fini=, 
stack_end=0x7fffcd575058) at libc-start.c:287
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -6800447105095750550, 
4196149, 140736638439520, 0, 0, 6800558367846640746, 6913429561201208426}, 
  mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x400840 
<__libc_csu_init>, 0x7fffcd575068}, data = {prev = 0x0, cleanup = 0x0, 
canceltype = 4196416}}}
not_first_call = 
#14 0x0040075e in _start ()

mdb_txn_begin appears to not being able to deal with env==NULL.

I can install more *dbg packages if needed for a better backtrace. Just let me
know.

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

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

Versions of packages dolphin depends on:
ii  libc6  2.19-22
ii  libdolphinvcs5 4:15.08.1-1
ii  libkf5baloo5   5.14.0-1
ii  libkf5baloowidgets515.08.0-2
ii  libkf5bookmarks5   5.14.0-1
ii  libkf5codecs5  5.14.0-1
ii  libkf5completion5  5.14.0-1
ii  libkf5configcore5  5.14.0-1
ii  libkf5configgui5   5.14.0-1
ii  libkf5configwidgets5   5.14.0-1
ii  libkf5coreaddons5  5.14.0-1
ii  libkf5dbusaddons5  5.14.0-1
ii  libkf5filemetadata35.14.0-1
ii  libkf5i18n55.14.0-1
ii  libkf5iconthemes5  5.14.0-1
ii  libkf5itemviews5   5.14.0-1
ii  libkf5jobwidgets5  5.14.0-1
ii  libkf5kcmutils55.14.0-1
ii  libkf5kiocore5 5.14.0-1
ii  libkf5kiofilewidgets5  5.14.0-1
ii  libkf5kiowidgets5  5.14.0-1
ii  libkf5newstuff55.14.0-1
ii  libkf5notifications5   5.14.0-1
ii  libkf5parts5   5.14.0-1
ii  libkf5service5 5.14.0-1
ii  libkf5solid5   5.14.0-2
ii  libkf5textwidgets5 5.14.0-1
ii  libkf5widgetsaddons5   5.14.0-1
ii  libkf5windowsystem55.14.0-1
ii  libkf5xmlgui5  5.14.0-1
ii  libphonon4qt5-44:4.8.3-2
ii  libqt5core5a   5.4.2+dfsg-9
ii  libqt5dbus55.4.2+dfsg-9
ii  libqt5gui5 5.4.2+dfsg-9
ii  libqt5widgets5 5.4.2+dfsg-9
ii  libqt5xml5 

Bug#782653: openmpi: (non-)reproducibility of build failure

[Willi Mann]

Hi!

Am 2015-04-19 um 00:29 schrieb Mario Lang:
 Willi Mann wi...@debian.org writes:
 
 was anybody of you able to reproduce this build failure in a clear
 chroot environment?
 
 No.
 
 I failed to reproduce it in a jessie pbuilder environment, and also on
 an another machine (mixed jessie/wheezy).
 
 Hmm, for me, it works in a clean pbuilder, but fails on every normal
 installation box (sid and jessie) I tried (I tried three, two sid and
 one jessie box).  Simon tried a fresh VirutalBox jessie install, which
 also fails.  I am guessing we are missing a Build-Conflicts.  But I
 haven't been able to identify it yet.


It seems that the problem is that timestamp on the libtool.m4 file is
too old. My guess is that in MET, the timestamp somehow underflows. By
setting the timestamp to 1980 (instead of 1970) the problem disappears,
at least on my machine.

In clean pbuilder environments, you probably do not have the timezone
set, so the 1970 timestamp does not underflow...

Attached patch fixes the problem for me. Mario, Simon, can you confirm?

WM


diff --git a/debian/patches/ompi_autogen_sh.patch b/debian/patches/ompi_autogen_sh.patch
index 0429388..7c655f3 100644
--- a/debian/patches/ompi_autogen_sh.patch
+++ b/debian/patches/ompi_autogen_sh.patch
@@ -5,7 +5,7 @@
  fi
  
 +# Ensure libtool.m4 is very old so that make does not rebuild aclocal.m4
-+touch -t 19700101.00 config/libtool.m4
++touch -t 19800101.00 config/libtool.m4
 +
  run_and_check $ompi_autoconf
  


signature.asc
Description: OpenPGP digital signature

Bug#782653: openmpi: (non-)reproducibility of build failure

[Willi Mann]

Hi,

was anybody of you able to reproduce this build failure in a clear
chroot environment? I failed to reproduce it in a jessie pbuilder
environment, and also on an another machine (mixed jessie/wheezy).

WM



signature.asc
Description: OpenPGP digital signature

Bug#782033: kexec-tools: bug only when sysvinit is used

[Willi Mann]

Hi,

I could only reproduce this bug with sysvinit as init system. I think
one could use runlevel (if it exists) to detect whether a real shutdown
is running. Maybe something like the attached patch could fix the
problem (not yet tested).

WM
diff --git a/debian/kexec-load.init.d b/debian/kexec-load.init.d
index 28306a7..f4de112 100644
--- a/debian/kexec-load.init.d
+++ b/debian/kexec-load.init.d
@@ -109,6 +109,9 @@ case $1 in
 			exit 0
 		fi
 	fi
+	if [ -x /sbin/runlevel -a $(runlevel | awk '{ print $2 }') != 6 ]; then 
+		exit 0
+	fi
 	do_stop
 	;;
   *)


signature.asc
Description: OpenPGP digital signature

Bug#745195: fixed, but more testing intended

[Willi Mann]

Just a status update on this bug: The upload of unrtf 0.21.5-3 fixes
this bug, but I intend to do more testing before asking for an unblock.


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

Bug#745195: status

[Willi Mann]

Control: tag -1 + pending

I've upgraded this bug to RC status because it is a regression from
wheezy. It is especially bad because it may bite some reverse
dependencies that use unrtf as part of a processing chain.

Salvatore Bonaccorso has already proposed a fix for this bug, based on
the upstream fix in newer versions.

WM


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

Bug#772811: unrtf: fixes for stable (CVE-2014-9274 CVE-2014-9275)

[Willi Mann]

Hi,

Just in order to avoid duplicate effort: I have prepared (but not yet
tested) an upload for wheezy-security of unrtf, fixing CVE-2014-9274
CVE-2014-9275. It is available in the alioth git repository:

http://anonscm.debian.org/cgit/collab-maint/unrtf.git/

Bye
Willi



signature.asc
Description: OpenPGP digital signature

Bug#772811: unrtf: CVE-2014-9274 CVE-2014-9275

[Willi Mann]

Hi Salvatore,

we were working in parallel unfortunately, as I prepared the same
patches in the morning. However, I also added 2 patches by
Fabian Keil. I'll upload tomorrow in the evening, you can have a look  at

http://anonscm.debian.org/cgit/collab-maint/unrtf.git/

comments welcome.

thanks
Willi

Am 2014-12-21 um 15:32 schrieb Salvatore Bonaccorso:
 Control: tags -1 + patch
 
 Hi Willi
 
 Attached are two patches separated per CVEs.
 
 Regards,
 Salvatore
 


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

Bug#772811: unrtf: CVE-2014-9274 CVE-2014-9275

[Willi Mann]

Hi Dave,

does 0.21.7 solve both security issues reported? If yes, could point
send me the individual patches that fix these issues? The Debian branch
for the next stable distribution is already frozen, so I cannot fix
these bugs with new upstream versions.

thanks
Willi

Am 2014-12-11 um 12:16 schrieb Moritz Muehlenhoff:
 Package: unrtf
 Severity: grave
 Tags: security
 
 Please see http://www.openwall.com/lists/oss-security/2014/12/03/4
 for more information and references to patches.
 
 Cheers,
 Moritz
 


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

Bug#755834: Fails to install if interface list is empty

[Willi Mann]

Package: isc-dhcp-server
Version: 4.3.0+dfsg-1
Severity: serious

Hi,

with systemd installed, isc-dhcp-server fails to install because starting the
daemon fails. This must have worked (in the sense that the postinst script 
succeeded) with sysvinit as I have the same (non-)setup of isc-dhcp-server
since ages. It's only installed because it is a dependency of fai-quickstart.
So the bug might need to be reassigned to systemd.


Setting up isc-dhcp-server (4.3.0+dfsg-1) ...
Job for isc-dhcp-server.service failed. See 'systemctl status 
isc-dhcp-server.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript isc-dhcp-server, action start failed.
dpkg: error processing package isc-dhcp-server (--configure):


# cat /etc/default/isc-dhcp-server
# Defaults for dhcp initscript
# sourced by /etc/init.d/dhcp
# installed at /etc/default/isc-dhcp-server by the maintainer scripts

#
# This is a POSIX shell fragment
#

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#   Separate multiple interfaces with spaces, e.g. eth0 eth1.
INTERFACES=
---snip---


The config file /etc/dhcpd/dhcpd.conf is identical to what's shipped in the
package (apart from commented lines)


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages isc-dhcp-server depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  debianutils4.4
ii  isc-dhcp-common4.3.0+dfsg-1
ii  libc6  2.19-7
ii  lsb-base   4.1+Debian13

isc-dhcp-server recommends no packages.

Versions of packages isc-dhcp-server suggests:
pn  isc-dhcp-server-ldap  none

-- Configuration Files:
/etc/dhcp/dhcpd.conf changed:
ddns-update-style none;
option domain-name example.org;
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;


-- debconf information:
  isc-dhcp-server/interfaces:
  isc-dhcp-server/config_warn:


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

Bug#754538: sqwebmail fails to install due to non-existant /var/www directory

[Willi Mann]

Package: sqwebmail
Version: 0.73.1-1.2
Severity: serious
Justification: fails to install

Hi Racke,

sqwebmail fails to install if the directory /var/www does not exist (which 
apparently does not exist if nginx is installed as httpd-cgi):

Entpacken von sqwebmail (0.73.1-1.2) ...
Trigger für man-db (2.6.7.1-1) werden verarbeitet ...
sqwebmail (0.73.1-1.2) wird eingerichtet ...
ln: die symbolische Verknüpfung „/var/www/sqwebmail“ konnte nicht angelegt 
werden: Datei oder Verzeichnis nicht gefunden
dpkg: Fehler beim Bearbeiten des Paketes sqwebmail (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 sqwebmail

Should be easy to fix - I guess (but am not sure) the most proper way to fix
this is to ship /var/www as part of the sqwebmail package. If you create it
in the maintainer script, it is problematic to decide whether to delete it
on package removal.

Bye
Willi


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

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

Versions of packages sqwebmail depends on:
ii  courier-authlib 0.66.1-1
ii  courier-base0.73.1-1.2
ii  courier-maildrop0.73.1-1.2
ii  cron3.0pl1-124.1
ii  debconf [debconf-2.0]   1.5.53
ii  expect  5.45-5
ii  ingerman [ispell-dictionary]20131206-5
ii  ispell  3.3.02-6
ii  libc6   2.19-4
ii  libfam0 2.7.0-17.1
ii  libgdbm31.8.3-12+b1
ii  libldap-2.4-2   2.4.39-1
ii  libpcre31:8.31-5
ii  nginx-full [httpd-cgi]  1.6.0-1
ii  postfix [mail-transport-agent]  2.11.1-1

sqwebmail recommends no packages.

Versions of packages sqwebmail suggests:
pn  courier-doc  none
pn  courier-pcp  none
ii  gnupg1.4.16-1.2

-- debconf information:
  sqwebmail/install-www-backup: symlink
  sqwebmail/install-www: symlink
  sqwebmail/calendarmode: local
  sqwebmail/dictionary: default


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

Bug#754538: sqwebmail fails to install due to non-existant /var/www directory

[Willi Mann]

 Should be easy to fix - I guess (but am not sure) the most proper way to fix
 this is to ship /var/www as part of the sqwebmail package. If you create it
 in the maintainer script, it is problematic to decide whether to delete it
 on package removal.

 
 It is quite likely that nowadays a different directory is used for installing 
 web
 applications, can you please check policy / file system standard?

Policy:

https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl

I would read that as to for now still use /var/www. (There are
discussions to use a subdirectory of /var/www as the real root, and some
people propose completely different locations, see e.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730382

)

Bye
WM


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

Bug#749129: possible fix

[Willi Mann]

Control: tag -1 + patch

Attached is a possible fix for this bug. I would like to get
maintainer's feedback before uploading it because it is quite intrusive
for an NMU.

The patch changes upstream's mkesmtpdcert, which is used by the
currently failing maintainer script, to allow specification of the
filename for the certificate.

The maintainer script is changed to create the certificate in a
temporary directory, to avoid idempotency problems (interrupt when
mkesmptdcert is run).

WM
diff --git a/courier/module.esmtp/mkesmtpdcert.in b/courier/module.esmtp/mkesmtpdcert.in
index 03b055e..f61d8cf 100644
--- a/courier/module.esmtp/mkesmtpdcert.in
+++ b/courier/module.esmtp/mkesmtpdcert.in
@@ -8,6 +8,12 @@
 # ESMTP STARTTLS.  Normally this script would get called by an automatic
 # package installation routine.
 
+PEMFILE=$1
+
+if [ -z $PEMFILE ]; then
+	PEMFILE=@mydatadir@/esmtpd.pem
+fi
+
 if test @ssllib@ = openssl
 then
 	test -x @OPENSSL@ || exit 0
@@ -15,17 +21,17 @@ else
 	test -x @CERTTOOL@ || exit 0
 fi
 
-if test -f @mydatadir@/esmtpd.pem
+if test -f $PEMFILE
 then
-	echo @mydatadir@/esmtpd.pem already exists.
+	echo $PEMFILE already exists.
 	exit 1
 fi
 
 cleanup() {
-	rm -f @mydatadir@/esmtpd.rand
-	rm -f @mydatadir@/esmtpd.pem
-	rm -f @mydatadir@/esmtpd.key
-	rm -f @mydatadir@/esmtpd.cert
+	rm -f $PEMFILE.rand
+	rm -f $PEMFILE
+	rm -f $PEMFILE.key
+	rm -f $PEMFILE.cert
 	exit 1
 }
 
@@ -36,16 +42,19 @@ set -e
 
 if test @ssllib@ = openssl
 then
-	cp /dev/null @mydatadir@/esmtpd.pem
-	chmod 600 @mydatadir@/esmtpd.pem
-	chown @mailuser@ @mydatadir@/esmtpd.pem
-	dd if=@RANDOMV@ of=@mydatadir@/esmtpd.rand count=1 2/dev/null
+	cp /dev/null $PEMFILE
+	chmod 600 $PEMFILE
+	chown @mailuser@ $PEMFILE
+	dd if=@RANDOMV@ of=$PEMFILE.rand count=1 2/dev/null
 	@OPENSSL@ req -new -x509 -days 365 -nodes \
-		  -config @sysconfdir@/esmtpd.cnf -out @mydatadir@/esmtpd.pem -keyout @mydatadir@/esmtpd.pem || cleanup
-	@OPENSSL@ gendh -rand @mydatadir@/esmtpd.rand 512 @mydatadir@/esmtpd.pem || cleanup
-	@OPENSSL@ x509 -subject -dates -fingerprint -noout -in @mydatadir@/esmtpd.pem || cleanup
-	rm -f @mydatadir@/esmtpd.rand
+		  -config @sysconfdir@/esmtpd.cnf -out $PEMFILE -keyout $PEMFILE || cleanup
+	@OPENSSL@ gendh -rand $PEMFILE.rand 512 $PEMFILE || cleanup
+	@OPENSSL@ x509 -subject -dates -fingerprint -noout -in $PEMFILE || cleanup
+	rm -f $PEMFILE.rand
 else
+	echo @CERTTOOL@ is not supported in debian
+	exit 1
+
 	if test $BITS = 
 	then
 		BITS=high
diff --git a/debian/changelog b/debian/changelog
index 25d4cce..b78158e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+courier (0.73.1-1.2) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Change mkesmptdcert to make cert-filename controllable by parameter.
+  * Create esmptd.pem in temporary path and then move it to /etc/courier.
+This way, mkesmptdcert no longer has to work on an dangling symlink as
+destination. (closes: #749129)
+
+ -- Willi Mann wi...@debian.org  Mon, 26 May 2014 18:23:21 +0200
+
 courier (0.73.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload in coordination with maintainer.
diff --git a/debian/correctpermissions.pl b/debian/correctpermissions.pl
old mode 100644
new mode 100755
diff --git a/debian/courier-mta-ssl.postinst b/debian/courier-mta-ssl.postinst
index 89c967e..ae3cce9 100644
--- a/debian/courier-mta-ssl.postinst
+++ b/debian/courier-mta-ssl.postinst
@@ -27,8 +27,19 @@ if [ $1 = configure ]; then
 		ln -s /etc/courier/emtspd.pem /usr/lib/courier/emtspd.pem
 	fi
 	if [ ! -f /etc/courier/esmtpd.pem ]; then
-		mkesmtpdcert
-		chown daemon /etc/courier/esmtpd.pem
+
+		# create pem file in temporary directory, for full idempotency
+		TMPDIR=$(mktemp -d)
+		ESMTPDPEM=$TMPDIR/esmtpd.pem
+
+		# call patched mkesmtpdcert which allows to specify the filename as first paramter
+		mkesmtpdcert $ESMTPDPEM
+
+		chown daemon $ESMTPDPEM
+		mv $ESMTPDPEM /etc/courier/esmtpd.pem
+
+		# clean up
+		rm -fr $TMPDIR
 	fi
 fi
 
diff --git a/debian/courier_perms b/debian/courier_perms
old mode 100644
new mode 100755
diff --git a/debian/fixlinks b/debian/fixlinks
old mode 100644
new mode 100755

Bug#749931: ijsgutenprint: Fails on upgrade, with wheezy dpkg

[Willi Mann]

Package: ijsgutenprint
Version: 5.2.10-1
Severity: grave

Hi,

On upgrade, ijsgutenprint fails on wheezy:

Vorbereitung zum Ersetzen von ijsgutenprint 5.2.9-1 (durch 
.../ijsgutenprint_5.2.10-1_amd64.deb) ...
dpkg-maintscript-helper: error: command dir_to_symlink is unknown
Hint: upgrading dpkg to a newer version might help.

Usage: dpkg-maintscript-helper command parameter... -- 
maintainer-script-parameter...

Commands:
  supports command
Returns 0 (success) if the given command is supported, 1 otherwise.
  rm_conffile conffile [last-version [package]]
Remove obsolete conffile. Must be called in preinst, postinst and
postrm.
  mv_conffile old-conf new-conf [last-version [package]]
Rename a conffile. Must be called in preinst, postinst and postrm.
  help
Display this usage information.
dpkg: Fehler beim Bearbeiten von 
/var/cache/apt/archives/ijsgutenprint_5.2.10-1_amd64.deb (--unpack):
 Unterprozess neues pre-installation-Skript gab den Fehlerwert 1 zurÃŒck
dpkg-maintscript-helper: error: command dir_to_symlink is unknown
Hint: upgrading dpkg to a newer version might help.

Usage: dpkg-maintscript-helper command parameter... -- 
maintainer-script-parameter...

Commands:
  supports command
Returns 0 (success) if the given command is supported, 1 otherwise.
  rm_conffile conffile [last-version [package]]
Remove obsolete conffile. Must be called in preinst, postinst and
postrm.
  mv_conffile old-conf new-conf [last-version [package]]
Rename a conffile. Must be called in preinst, postinst and postrm.
  help
Display this usage information.
dpkg: Fehler beim AufrÀumen:
 Unterprozess neues post-removal-Skript gab den Fehlerwert 1 zurÃŒck


(Sorry for the partial german locale)

Since this might bite many users on upgrade from wheezy to jessie, I set the 
severity to grave.

-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ijsgutenprint depends on:
ii  ghostscript 9.05~dfsg-6.3+deb7u1
ii  libc6   2.18-5
iu  libgutenprint2  5.2.10-1
ii  libijs-0.35 0.35-8

Versions of packages ijsgutenprint recommends:
iu  foomatic-db-gutenprint  5.2.10-1

ijsgutenprint suggests no packages.

-- no debconf information


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

Bug#749129: courier-mta-ssl: fails to install

[Willi Mann]

Hi Racke,

   Selecting previously unselected package courier-mta-ssl.
   (Reading database ... 8752 files and directories currently installed.)
   Preparing to unpack .../courier-mta-ssl_0.73.1-1.1_amd64.deb ...
   Unpacking courier-mta-ssl (0.73.1-1.1) ...
   Setting up courier-mta-ssl (0.73.1-1.1) ...
   cp: not writing through dangling symlink '/usr/lib/courier/esmtpd.pem'

Which comes from mkesmtpdcert. I've looked at whether this could be
fixed easily by changing the maintainer script. Unfortunately, this is
not possible - or at least, I do not see it.

The easiest way would probably be to fix mkesmtdcert to work again with
/usr/lib/courier/esmtpd.pem being a dangling symlink.

Unfortunately, there is another problem: mkesmtpcert is not idempotent:
Since creating the certificate is a multi-command process, an interrupt
at one of those commands would mean that an bogus cert file gets
created. Further invocations would not detect that the cert is bogus. So
a real fix would be to create the certificate in a temporary place -
which would require even bigger modifications to mkesmtpdcert.

WM


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

Bug#741620: patches for RC-bugs

[Willi Mann]

tag 741620 + patch
thanks

Hi Racke,

I've created patches for the two RC-bugs against courier. The patch to
fix the STARTTLS problem is really tested, and fixed the problem in my
test setup. The patch to fix maildrop delivery mode really makes
maildrop to be linked against libcourierauth.so again, but I did not
test whether it fixes the whole problem (and the patch is not that
beautiful either, which are the two reasons  I'm not adding the patch
tag there).

Do you currently have time to prepare an upload? Otherwise, I would do
an NMU (after verifying that the second patch is also OK), but not
before Thursday.

Bye
Willi
From 43a0424d6de39643036c421dc185fae0086c44c2 Mon Sep 17 00:00:00 2001
From: Willi Mann wi...@wm1.at
Date: Sun, 27 Apr 2014 14:56:48 +0200
Subject: [PATCH 1/3] Fix maildrop to build against courier authlib

---
 debian/rules|1 +
 libs/maildrop/configure |7 ---
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/debian/rules b/debian/rules
index e3b1652..f8bbc9a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -50,6 +50,7 @@ COMMON_CONFOPTS=--prefix=/usr --mandir=\$${prefix}/share/man \
 		--with-calendardir=/var/run/courier/calendar \
 		--with-certsdir=/etc/courier \
 		--with-webadmindir=/usr/share/courier/webadmin \
+		--enable-authlib \
 		--enable-userdb \
 		--enable-syslog=1 \
 		--enable-unicode \
diff --git a/libs/maildrop/configure b/libs/maildrop/configure
index 0a600f1..c5f4433 100755
--- a/libs/maildrop/configure
+++ b/libs/maildrop/configure
@@ -16300,13 +16300,6 @@ fi
 done
 
 
-# When we're a part of the Courier build, we let Courier do the authlib stuff
-
-if test -d ${srcdir}/../../courier
-then
-	COURIERAUTHCONFIG=
-fi
-
 # Check whether --enable-authlib was given.
 if test ${enable_authlib+set} = set; then :
   enableval=$enable_authlib;
-- 
1.7.10.4

From 66c08f5188192c5825dde9d9264b9d95a56664d8 Mon Sep 17 00:00:00 2001
From: Willi Mann wi...@wm1.at
Date: Sun, 27 Apr 2014 15:02:05 +0200
Subject: [PATCH 2/3] Create dhparams in postinst

---
 debian/courier-ssl.postinst |7 +++
 debian/courier-ssl.postrm   |1 +
 2 files changed, 8 insertions(+)

diff --git a/debian/courier-ssl.postinst b/debian/courier-ssl.postinst
index 48e29b9..c09f6ae 100644
--- a/debian/courier-ssl.postinst
+++ b/debian/courier-ssl.postinst
@@ -20,4 +20,11 @@
 # Source debconf library
 . /usr/share/debconf/confmodule
 
+if [ $1 = configure ]; then
+	test -d /etc/courier || mkdir /etc/courier
+	if [ ! -f /etc/courier/dhparams.pem ]; then
+		mkdhparams
+	fi
+fi
+
 #DEBHELPER#
diff --git a/debian/courier-ssl.postrm b/debian/courier-ssl.postrm
index 48a6965..5c065f8 100644
--- a/debian/courier-ssl.postrm
+++ b/debian/courier-ssl.postrm
@@ -19,6 +19,7 @@
 
 if [ $1 = purge ]; then
 	rm -rf /var/lib/courier/couriersslcache
+	rm -rf /etc/courier/dhparams.pem
 fi
 
 #DEBHELPER#
-- 
1.7.10.4



signature.asc
Description: OpenPGP digital signature

Bug#740602: marking pending

[Willi Mann]

tag 740602 + pending
thanks

Marking this bug as pending as a fix is in pkgs repository:

http://anonscm.debian.org/gitweb/?p=pkg-games/deng.git;a=commitdiff;h=f7ffda75d23d1e471cf6a42f21d42e991a2172d3;hp=9b14820b38c3e1ea99b686bbc469a42c9bbef9b8

Greetings from Salzburg BSP
WM


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

Bug#741620: dhparams.pem missing...

[Willi Mann]

Apparently, the reason for this bug is that courier-imap now needs a
dhparams.pem. At least, I could reproduce this bug (using offlineimap),
and found the following message in network dump:

MEAE2 NO STARTTLS failed: couriertls: /etc/courier/dhparams.pem:
error:02001002:system library:fopen:No such file or directory\x0a

After creating a /etc/courier/dhparams.pem by

openssl dhparam -out dhparams.pem 2048

offlineimap was able to successfully download messages.

WM


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

Bug#633730: FTBFS now earlier in build process

[Willi Mann]

Hi,

I tried to reproduce this bug, but now, the package does not even build
in a clear amd64 chroot:

 libtool: link: ar cru .libs/libseed_multiprocessing.a  
 libseed_multiprocessing_la-seed-multiprocessing.o
 libtool: link: ranlib .libs/libseed_multiprocessing.a
 libtool: link: ( cd .libs  rm -f libseed_multiprocessing.la  ln -s 
 ../libseed_multiprocessing.la libseed_multiprocessing.la )
 make[4]: Leaving directory `/tmp/buildd/seed-3.8.1/modules/multiprocessing'
 Making all in readline
 make[4]: Entering directory `/tmp/buildd/seed-3.8.1/modules/readline'
 /bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
 -I../..   -D_FORTIFY_SOURCE=2 -I../../libseed/ -pthread 
 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
 -I/usr/include/gobject-introspection-1.0   -DG_DISABLE_ASSERT 
 -DG_DISABLE_CHECKS -DG_DISABLE_CAST_CHECKS  -g -O2 -fstack-protector 
 --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -Wall -c -o 
 libseed_readline_la-seed-readline.lo `test -f 'seed-readline.c' || echo 
 './'`seed-readline.c
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 
 -I../../libseed/ -pthread -I/usr/include/glib-2.0 
 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
 -I/usr/include/gobject-introspection-1.0 -DG_DISABLE_ASSERT 
 -DG_DISABLE_CHECKS -DG_DISABLE_CAST_CHECKS -g -O2 -fstack-protector 
 --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -Wall -c 
 seed-readline.c  -fPIC -DPIC -o .libs/libseed_readline_la-seed-readline.o
 seed-readline.c: In function 'seed_readline_bind':
 seed-readline.c:80:22: error: 'Function' undeclared (first use in this 
 function)
rl_bind_key(*key, (Function *) c);
   ^
 seed-readline.c:80:22: note: each undeclared identifier is reported only once 
 for each function it appears in
 seed-readline.c:80:32: error: expected expression before ')' token
rl_bind_key(*key, (Function *) c);
 ^
 seed-readline.c:73:16: warning: variable 'c' set but not used 
 [-Wunused-but-set-variable]
ffi_closure *c;
 ^
 make[4]: *** [libseed_readline_la-seed-readline.lo] Error 1
 make[4]: Leaving directory `/tmp/buildd/seed

WM


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

Bug#718697: ptop (debian package): RC bug

[Willi Mann]

Hi Bas,

Am 2013-12-26 23:18, schrieb Bas van den Dikkenberg:
 Sorry i missed the the mail we do asap
 
 But a littel correction on my last mail the autocorrect on the phone was wrong
 
 I was in the hospital for last 3 months wil try to fix this year

I'm sorry to hear that. Get well soon.

Bye
Willi


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

Bug#718697: ptop (debian package): RC bug

[Willi Mann]

Hi,

do you have any plans on updating your package ptop? According to the
CCed RC-bug, the version in sid does not work with the current postgres
version 9.3, so it would need to be updated.

If you need a sponsor for uploading this package, you can ask me.

thank you
Willi


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

Bug#682905: downgrading, as it only affects certain configurations

[Willi Mann]

Control: severity 682905 important

According to upstream, this bug only occurs in certain configurations
[1], and as far as I know, those configurations are by no means default
settings. So I'm downgrading this bug's severity to important.

WM

[1] http://www.mail-archive.com/enigmail-users@enigmail.net/msg00189.html


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

Bug#682905: can't import signatures

[Willi Mann]

Hi!

Am 2012-08-18 10:35, schrieb Daniel Pocock:
 
 
 On 18/08/12 08:22, Daniel Pocock wrote:

 Hmm, that may make it harder to reproduce it. Can you please send me
 your enigmail settings in the problematic profile:

 egrep -i enigmail|pgp ~/.icedove/*/prefs.js

 I attach prefs from the bad profile and the good profile

 Do any of the prefs look unusual?


No, as far as I can see, nothing unusual.

 
 Just a further update
 
 I stopped icedove, manually edited prefs.js to remove all the settings
 that don't exist in the good prefs.js from the other profile, and then
 started icedove again.
 
 However, it did not fix the problem.
 
 Does that egrep statement definitely find all relevant prefs?
 
 Are these related?
 
 user_pref(mail.identity.id1.defaultEncryptionPolicy, 0);
 user_pref(mail.identity.id1.encryptionpolicy, 0);

Yes, defaultEncryptionPolicy is also from enigmail (see
extensions/enigmail/ui/content/enigmailEditIdentity.js in the source).
However, I also have it set to 0, so this is nothing unusual.
encryptionpolicy is not from enigmail, at least not from current
versions as I cannot find the string in the source. However, this value
is also set to 0 in my profile, so it cannot be the culprit.

Do you use IMAP or POP3?

WM


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

Bug#682905: can't import signatures

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

 I've tried this.  I created a completely different profile using 
 ProfileManager and then I set up my account in the profile.
 
 I didn't set up everything, I have a lot of settings.  I just put
 my main email identity (dan...@pocock.com.au)
 
 I was able to successfully import signatures attached to emails -
 no error message

Thanks, the important thing is to know that the problem is specific to
your profile.

 BTW: Did you ever install enigmail as a local extension (i.e.
 downloaded it as xpi file from enigmail.mozdez.org or
 addons.mozilla.org)?
 
 I can't remember if I have ever done that.  I believe I started
 using the enigmail package from about 2010
 
 I have used icedove for a long time, and each time I upgrade Debian
 and Icedove, I keep using the same profile.  The oldest file under
 the ~/.icedove/profile directory is from 2007, but I may have had
 this profile since before that, I can't remember.

Hmm, that may make it harder to reproduce it. Can you please send me
your enigmail settings in the problematic profile:

egrep -i enigmail|pgp ~/.icedove/*/prefs.js

I'll try to reproduce the problem on my test box. This might take some
time because I currently have no access to it.

WM
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQJsiYAAoJEIy+IZx0V22BQkEP/iZe84HlJgf41uSCDN9iV1Zw
YJqiGlLYImNU4KS4C36YK2d9QzXZFOajNuoNXOJSTn/Kh9obU57yIo6ROAZoVroh
cM3i4I0Oy2d92sDJVp5PKP+ZxnYPmS1zHJOhWT+1kVT5aSZjalNhdvw7RetqPGoK
AW2BpLA/o0eHfMQ5bWWhEvEbpC9MjYUCpAiYo/dY5zooEHKKOo/9XVPxDyOi3cPz
rPjC+YD0irRVyCyLjycrPDSxEh/eaIH8+n3P9tW608guHGPCX+CpCkU6a82H138H
LzI400yHzg1ZDv9tQndsdVeEpFzJjyG73mHLoFXlrhUU+noegqrD1ki5O17Aw53t
VUrbNZa0V0vhTWvlH+//l/fJkjioR1V24Md10mi8TrIJMN0StIR2BBQMCjMDlh8n
mMcH303X8kcLnDbOr2LLGEwBY3Ykv4NlNR/CMkwOFH7TFOcMsSTsMc0itBdG1LuF
VXx4ANjgI/5iDjzwwmdZYqtNOh89x0ccOdoXjUlWJE4TJ3TK5XTRcgigGgeVyaf3
LAfX0JbJcOUldvQwIIBqG+dRVVzZHmdRZ1cafYfw0M1XPMg2DNM9beVxKX9ToCZH
iHJ4tJc0m1zV34j/qF1OfIpoaj81ZMYSbjY/k8h0ubcrsoZ8qq3BwElwgj5wBgKD
U5HQGviN4+6zyWpiTZ7Y
=ouGx
-END PGP SIGNATURE-


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

Bug#682905: [PING] Re: Bug#682905: can't import signatures

[Willi Mann]

Hi Daniel!

Have you received my last mail concerning this bug?

WM


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

Bug#682905: can't import signatures

[Willi Mann]

Am 2012-07-29 17:37, schrieb Daniel Pocock:

 I've done that and I've broken the log into 3 parts:
 
 - startup phase
 
 - access the message
 
 - log messages that appear when I click the `Import PGP key' menu option

Thank you. At least we know that gpg does not receive the data from the
attachment (outputLen=1).

 You could also try with another local user account on that machine, to
 rule out that it is due to specific settings in your home directory.
 
 I created a new UNIX user, new email address and new PGP key
 
 I sent an arbitrary attachment to the user (using the PGP/MIME
 attachment style) and the user was able to save the attachment
 
 I then used caff to sign the user's key and send the sig to the user
 
 The user was able to access the attachment and import the sig
 
 Therefore, it appears to be good for a completely clean user account

That's partially good news. Let's narrow it down further. Please create
a new icedove profile within your existing user account (icedove
-ProfileManager on the command-line, when no instance of icedove is
running). and do essentially the same you did within the new user
account. That way, we make sure that it is your icedove profile, not
your whole user account that accounts for these problems.

 I am willing to try swapping out my own user profile somehow to isolate
 the problem, but (a) I do want to preserve my settings and (b) that
 won't be a good solution for all users upgrading from squeeze-wheezy
 
 Particular features of my user account:
 - was working fine with squeeze
 - gpg: includes an old 1024 bit key, now revoked
 - icedove: includes enigmail and iceowl-extension

I think it is unlikely that iceowl causes incompatibilities, but to be
sure about it, you could temporarily disable all extensions except enigmail.

BTW: Did you ever install enigmail as a local extension (i.e. downloaded
it as xpi file from enigmail.mozdez.org or addons.mozilla.org)?

WM


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

Bug#682905: can't import signatures

[Willi Mann]

Hi!

 I have the latest icedove and enigmail packages from wheezy, icedove is
 10.0.5-1
 
 The messages (usually sent to me by a user with caff) are decrypted
 successfully.
 
 However, when I click to save the attached signature, a 0 byte file is
 created.  icedove reports the attachment is 2.3kb - but the file created
 in /tmp is 0 bytes.

I regularly receive messages sent by caff and I can save the attachment
just fine (with enigmail+icedove from wheezy).

 If I use another machine with squeeze (icedove+enigmail), everything is
 fine.

On the same message?

 I can also manually save the sigs on the squeeze machine, copy them to
 the wheezy machine, and then import them to gpg from the command line:

Could you check whether the message source (Ctrl+U) as shown by icedove
squeeze vs wheezy is identical?

WM


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

Bug#682905: can't import signatures

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

Am 2012-07-27 17:39, schrieb Daniel Pocock:
 Maybe there is an issue in my configuration and enigmail is hiding
 the error or something - I'm quite happy to look at the issue in
 more detail if you can suggest how to proceed

Please enable logging and send me the log when you try to open an
attachment. Logging can be enabled in the last tab of the enigmail
settings dialog - simply set a directory (e.g. /tmp/ on a single-user
system) and restart icedove.

You could also try with another local user account on that machine, to
rule out that it is due to specific settings in your home directory.

WM
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQEuYSAAoJEIy+IZx0V22BbAIQAJHDZ9zXbuJy+PCHe2ripLdy
PyPCeAKiq7q4PcrPCWrsSjlwjyYvJ9C+N4mR0H2idwtjmUCk2AhUb+laKRo5MoNf
DiG3IBNbeC04+wXUx0dfhJJ+HxX9BdqF5PhqaHP8PgMY7yKCo0UmsjSoW9bhyWcl
+2CjSaKFOybxWg3rayHz6Ey2s8mzbxsowosYArOFkRcr9ILSE1cJjT8CzbXIhQaE
BicnzprkSlyTjxiYTzTRtL7Ya1tJKSPis1MI3z23DLUP4mldhIzdMuDRTHZQeQ1b
HdDGdPU2c+i7A/Olc0UTWLBV10oQg/uc+A8PiOgeHhO5fd1F0uWAnySVlvCEWRHK
MltoAQfLV+sT3GyUccKuqNWB3gRMzJxJKwm1wZkkqSTgeahBhnJo/N3AK+JGFezB
QLDOuo8HxvyUtyWBb1EY7lzFH2ZE75WZXN+tfluJOpjXyg2RGDcdy5udmTfb0uce
zMnNhHkCLXOy31CYFD1/+YzAQE+NYKtX/y5bry12/Xob9ZQrQnmUyv/o3myu9TCw
ZWdJR7SMsMOLVt0aFkxAsPhwKFr+sBCRMOf2eAjEhxTdved5QHgW6NVJaVezZQiZ
anNCyfAVTOA5uN+cQ7Rex3ZhtCRaVjdJE3I/I4lMBiapNimiMVYVYlBolKsArBpP
zA81azWdHBjr91Dc9yBi
=LY0W
-END PGP SIGNATURE-


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

Bug#678575: bug currently only affects experimental

[Willi Mann]

tag 678575 + experimental
thanks

This bug currently only affects experimental, marking it as such.

WM


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

Bug#661991: should libtrash be removed?

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

clone 661991 -1
retitle -1 RM: libtrash -- RoM; RC-buggy; abandoned upstream
severity -1 normal
reassign -1 ftp.debian.org

As requested by the maintainer (see bug log), please remove libtrash
from unstable. It is RC-buggy and unmaintained upstream. It does not
have any reverse dependencies.

Best Regards
Willi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJP4CI8AAoJEIy+IZx0V22BAg0P/jPYXnV6Z6ic0kGtCPjYjWaX
RBKdI2P/wJ76IWU3/FpPXjhfy3HL1BPlRguhk5gLALemV6Jfe1yuQo0uJGoZnBtY
0/r/skl5qRFWvn/Yhu1ByEKqI6CbV5/Fm8iHz8XgMXkYvr6n1ndB+u+N6GdorOIS
uy605w3KHwbHLdFGQU+2as9Slz7yLSuam7J5vPZebAZbTccp7FM4NRUzJVvFjp0j
tlBoKOqsfBfEQDrVhO90XJ1fDWNwwRX+437xbJuPIZid968bwbwM6Ec+kohtT6if
Xmf7KSYNY5RzfOMDr8oRb7XG2iCZ8FpFJFh/AFdgLAERomkfc0/R4HEd+iOyId4k
U1Kp8bHc6rcEQZ+qS5AevvlaX6JyE6RkSsWpeh9c8DPC2lQZ1AfspJ21eP8/KlpX
v1i/cDDcO/kyzYplyuBTIQfXpc0gMR18GVGo9HZRHcD6hwfVIq8kY1WitJiTikyP
rfE5D4TK3YxJA807fHvwFp09JAE3DK6BcNE+GzKmos5hAkp/PkCazFD7MtNeIoaH
edKhVDXyrwjOtxzjkqFvnvfcEoyCPHoX1gO8KCshu0en3qWxurS6u7VRuhQhKV99
6R2RPLsJqcCmib9OmYGy7zKVFRZczt1CVQ74H0MB+Q/VnHzXRayPy2Lszl9j7Zxa
/Wx/k0dAfvGFzGLZexol
=yxxs
-END PGP SIGNATURE-



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

Bug#661991: should libtrash be removed?

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

clone 661991 -1
reopen -1
retitle -1 RM: libtrash/2.4-2
severity -1 normal
reassign -1 release.debian.org
user -1 release.debian@packages.debian.org
usertag -1 rm
thanks

libtrash has been removed from unstable (#678094) because it was
RC-buggy and is unmaintained upstream. The very same version is in
squeeze and the RC bug (which boils down to: does not work at all
except partially producing segfaults) is also reproducible - see bug
log for details. The maintainer agrees that libtrash should be
removed, so please remove libtrash from squeeze.

Best Regards
Willi

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJP4M+KAAoJEIy+IZx0V22BZZMP/1dmCtgtLZRoI+XTjn4a69lY
Lo5ItNFw2Mo6NZf+hhpg+mEx2S3tV7+MJBZgs5DlMrY35qOSA9mIiFPspNKO6pCa
ieJT7BSnQliOMWtmXqJ4fT7U0ksyeNSWEQL63mfNAZXp5NDrPRSMZrtTK4qETbiY
jKm/KuHrzGHf0+EqHdCK47O7C6PRJZSlzxNSDSdUvBv5OrSF/ai+2hJdzYVD3mQy
+HjgAmA8sQn2ZV8+viVGvYfkN0RLuDzTTYwnslFCDagMS9xPIixWTTOT7yI6BHS/
HpqCWEaSD/n20zILbV99K05qZlX0NZbQh+goqfzvzqwBrfar4hXz/EsggmpEmbj4
+icb1E02HnhAhXLaO5gfhLuC0eBZ/YRE4i4oXqPLB1Q7G4XkMgFAZCFhb7hYo9YB
kfNna6nzfmKasUvD9sLs8bOcQjkLwybS/Hf93dUT1fTXfqHUFq3NakTJSnE8XnGv
EfIMx55zcutvAjlp3jPWjRY29RiJGalxKjEPrj13OgyA3D0lvXwCBkuQ7uwGyRxG
w9HzgZNqO7pDKzKzT4fcOdzcWZLZKVCq5srOWwOMfBJkcj/MVdina+tgf7HsdjyC
zXd3Z7ZoUvKp94iUoFXMwciKAHEFefNzeIw6CVcHluEFp/uK4qMco0N/XPeFaC6L
obGGSiMB/Q25Hx+wp3Cc
=z0Vy
-END PGP SIGNATURE-



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

Bug#627508: conflicting binary path for dconf and d-conf

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

Both the package dconf and d-conf with its binary package dconf-tools
ship a binary with the path /usr/bin/dconf. d-conf is a utility that
originates from gnome, and whose purpose is to manage Desktop
Environment Settings. On the other hand, dconf is a utility to dump
certain information of a system's state (configuration?).

Although dconf probably predates d-conf, I think it is very unlikely
to get path within d-conf changed: dconf-tools is installed on more
than 1 systems, while dconf is only installed on about 170 systems.

My recommendation is to rename the binary of dconf. Maybe the binaries
name could be changed to confdumper?

Greetings from Salzburg BSP
Willi

[1] http://qa.debian.org/popcon.php?package=d-conf
[2] http://qa.debian.org/popcon.php?package=dconf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJP3cCuAAoJEIy+IZx0V22BpzAQAK3tQI9B5az8wMwQquBTBnaR
QfZ+k1Z1HnBGH6rXjS1CHh3FNXi/JMktsXMYTSHsTyqvKiZ9/bbgeHDMZq75An4O
TYt31wSB4jFpWY8dfILBCRT4n0WXZWwyWI7dAH4hatW8LJa1AqDTOtWj5kDqF8IL
QPBDOr+eueF49PP782jFx26BVFW+cOimsmY45Ekwsg5r4I0eQenabiL5YyjSm8uJ
kZDOlK/kGs0GBD6dbsFY30eigHGyVCq59WESaogZ/v4Bc2+ufSDIUH92deBXzTTv
j1+3NdhTBJqkZas1vKGv+Np0IW/QNpRTtr4yYsS/wS/Tv5cGHJCsUvxnEh2uG7yT
qR0xwSKtO2HnQJ9RaewkeEk5MWNFV1SrgK3ZN7btk22KqX6xcOPGiazZ5/E0LSNa
2WzHCmtPHmGrx5YYn+hMB5lu8PBUmQhASSbgZAhY4FOiDyn1r+pnRceZy4duaiK4
gi+OCWNUNELfSLjdRPyO4KPzhDdSWPyMCsMBmtNqvQl0ohPPN5R46dulxV2o+V+D
2nm//o2+sTz3zBtljZ5ee2QnwSF0iBpKVS/AGNOq3lbsOyvSyL4p6cjlvidHpzy8
flHT7PX/J4w/keY41rkbemmBKINvKrzFvsRlX0SLQn5NqyU9i4MYO34Jeu8poQT8
Im5NFqJpa9cpD7a/8GGs
=0gd0
-END PGP SIGNATURE-



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

Bug#668663: nmu intended

[Willi Mann]

Hi!

I intend to upload an NMU to fix this bug. The debdiff is attached.

Greetings from Salzburg BSP
Willi
diff -Nru gtimer-2.0.0/debian/changelog gtimer-2.0.0/debian/changelog
--- gtimer-2.0.0/debian/changelog	2011-08-06 10:07:30.0 +0200
+++ gtimer-2.0.0/debian/changelog	2012-06-17 17:29:32.0 +0200
@@ -1,3 +1,10 @@
+gtimer (2.0.0-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix segfault due to uninitialized variable. closes: #668663.
+
+ -- Willi Mann wi...@debian.org  Sun, 17 Jun 2012 17:26:30 +0200
+
 gtimer (2.0.0-1) unstable; urgency=low
 
   * Update watch file
diff -Nru gtimer-2.0.0/debian/patches/fix-segfault-due-to-uninitialized-variable gtimer-2.0.0/debian/patches/fix-segfault-due-to-uninitialized-variable
--- gtimer-2.0.0/debian/patches/fix-segfault-due-to-uninitialized-variable	1970-01-01 01:00:00.0 +0100
+++ gtimer-2.0.0/debian/patches/fix-segfault-due-to-uninitialized-variable	2012-06-17 17:26:00.0 +0200
@@ -0,0 +1,17 @@
+Description: Fix Segfault due to uninitialized Variable
+ A pointer intended to hold a possible error message was not initialized prior
+ to being passed to the corresponding gtk function. Initialize the pointer with NULL.
+Author: Willi Mann wi...@debian.org
+Bug-Debian: http://bugs.debian.org/668663
+
+--- gtimer-2.0.0.orig/main.c
 gtimer-2.0.0/main.c
+@@ -2027,7 +2027,7 @@ static GtkWidget *create_main_window_men
+ //  GtkUIManager *uimanager;
+   GtkActionGroup *actgroup;
+   GtkAction *item;
+-  GError *err;
++  GError *err = NULL;
+ 
+   actgroup = gtk_action_group_new(ActionMain);
+   // set translation domain and function
diff -Nru gtimer-2.0.0/debian/patches/series gtimer-2.0.0/debian/patches/series
--- gtimer-2.0.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ gtimer-2.0.0/debian/patches/series	2012-06-17 17:21:27.0 +0200
@@ -0,0 +1 @@
+fix-segfault-due-to-uninitialized-variable

Bug#666227: will upload NMU

[Willi Mann]

Hi!

In order to fix this bug, I'll NMU this package with attached changes.

Greetings from Salzburg BSP
Willi
diff -Nru tgif-4.2.5/debian/changelog tgif-4.2.5/debian/changelog
--- tgif-4.2.5/debian/changelog	2012-04-16 09:20:31.0 +0200
+++ tgif-4.2.5/debian/changelog	2012-06-16 13:23:37.0 +0200
@@ -1,3 +1,11 @@
+tgif (1:4.2.5-1.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/preinst: Also support clean installation when package was previously
+removed but not purged. closes: #666227
+
+ -- Willi Mann wi...@debian.org  Sat, 16 Jun 2012 13:05:52 +0200
+
 tgif (1:4.2.5-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru tgif-4.2.5/debian/preinst tgif-4.2.5/debian/preinst
--- tgif-4.2.5/debian/preinst	2011-03-01 23:46:59.0 +0100
+++ tgif-4.2.5/debian/preinst	2012-06-16 13:13:08.0 +0200
@@ -3,24 +3,26 @@
 #DEBHELPER#
 
 case $1 in
-   install|abort-upgrade ) 
+   abort-upgrade ) 
exit 0
;;
-   upgrade )
-   # Remove old config file if upgrading from tgif = 3.0p13-1
-   rm -rf /etc/X11/tgif
-   # Clean up app-defaults files from previous versions of the postinst
-   # script tgif ( 4.2.2-4).  This should restore the files to their
-   # pristine state unless the user has made additional alterations.
-   for bit in  /ja_JP.eucJP /ru; do
-   file=/etc/X11$bit/app-defaults/Tgif
-   # Remove all instances of the 
-   #   Tgif*InitialPaperSize:
-   #   Tgif*GridSystem:
-   # line pairs appended by old versions of postinst.
-   sed '/Tgif\*InitialPaperSize/,+1 d' $file  $file.clean
-   mv $file.clean $file
-   done
+   install|upgrade )
+   if [ ! -z $2 ]; then
+  # Remove old config file if upgrading from tgif = 3.0p13-1
+  rm -rf /etc/X11/tgif
+  # Clean up app-defaults files from previous versions of the postinst
+  # script tgif ( 4.2.2-4).  This should restore the files to their
+  # pristine state unless the user has made additional alterations.
+  for bit in  /ja_JP.eucJP /ru; do
+  file=/etc/X11$bit/app-defaults/Tgif
+  # Remove all instances of the 
+  #   Tgif*InitialPaperSize:
+  #   Tgif*GridSystem:
+  # line pairs appended by old versions of postinst.
+  sed '/Tgif\*InitialPaperSize/,+1 d' $file  $file.clean
+  mv $file.clean $file
+  done
+   fi
;;
* )
echo preinst called with unknown argument \`$1' 2

Bug#661991: should libtrash be removed?

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

Your package libtrash has an RC bug since the beginning of march. The
bug can easily be reproduced on amd64: It does not save files from
being deleted, but it causes a segfault in in vim and other binaries.
But even on i386, the package does not appear to work as explained in
the documentation - I also could not get it to rescue any file I
deleted with rm. It only created SYSTEM_ROOT within ~/Trash.

I tried to debug the Segfault on amd64, but I could not gain any
further insight as the breakpoints I set were ignored, and the
backtrace I got with valgrind did not fit what I saw in the source code.

I'm wondering whether the package should be removed, as the latest
upstream version is 3.2, which was released in 2008, so it seems
pretty much unmaintained. The latest upload also dates back to 2008.
Also, the package does not have any reverse dependencies.

Note that problems I mentioned can also reproduced in stable, so if
the package is removed from testing, it should probably also get
removed from stable.

Greetings from Salzburg BSP
Willi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJP3OF+AAoJEIy+IZx0V22BjgkP/0J72jvH2G0N/u5Vv6qJhIHK
apozNd6QAoQvUESqoLdUKHH7HzkKcD278CmS16h1MWuhSE+BvFkgfw9UmaKTUsjA
p/H2Um/qOZXj0vAkR8J5QIx/v+9QGa3X/zCYOKN+bdRoprSgSVz95H9QY3VgKsG6
NeZ6vUlXYFqATelhEm3kELonl4dNo+CMckJMyKFQMRDTucxhiPe6KzE61U+H5P08
4ygN30omqJMGWa1DYeBKX5+ZbQylgd0C3iuIKEWoh9itZywbVJ8GVOTsuQ2hp6/F
ZIQWjdhp6DUgFrhhPbD7k4OC72mKy23l9ojF3L0YtQFtlrZ+h9YBRedZaz3OUlJ4
cnE28IJkW5589v3fzyf8f4s536GTT5xWUzIJ3deMjfRXcPNszcnqcGs6M3d+WMkC
VFPnCKrr0HxN68llbVuZw1QLwp/hWSVrpkrF+e48V/szYnj2SUbXMRBOzyPk0zJ7
ljG8iSbmUUS+h5bqU6F0m80Wd9vBqbrL+U/ckzOAKjJWyTvSKLsLSW0iI7+FHWn9
4jOAKZ6umAEkL8QDkW+5Vz6yC/C3dgnOyulaWkvRVRVmNXCTsMqJ5N4McFyAUmqX
JJJZtbXYfEI4vrXMQvg9wfn9bQVrnGzePz1sYbgGd0cUe5uPOxvobYmVbKCYeFYN
Cm33BjvqCIEdRs9XBO/u
=/Kll
-END PGP SIGNATURE-



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

Bug#626019: libsane-perl: Proposal on how to track this down

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

Am 2012-05-14 20:37, schrieb Jeffrey Ratcliffe:
 It is certainly doable, but my first problem is that I have not 
 managed to reproduce the issue.

As I already said in the bug report, I could reproduce the issue on
one of my amd64 (Linux) systems. However, it does not fail on every
attempt.

 If I could get access to a machine which reliably reproduced the 
 problem, it would certainly be quicker to add some print statements
 to the .xs to work out what was going on rather than spend time on 
 porting the tests to c.

I guess you won't find a machine where it fails on every attempt. In
principal, I could give you access to the amd64 box where I can
reproduce the issue. Unfortunately, the machine is behind DSL with
dynamic IP, so granting access is not exactly trivial.

 I am in half a mind to disable the tests and then deal with any
 bug reports from the problematic archectures. At least there then
 might be a user on a suitable machine and motivated to help.

At least for the wheezy release, this sounds like a sane approach to
me - as long as nobody reports a hang in a real-world scenario.

WM
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPsW99AAoJEIy+IZx0V22BBhkP/RsWvPnbdphObu9y8ySK4pcI
wVriIL9iBexOlzeJC0For7vzaGlKu4VvBfPcA+gF735OgUnTh0hTp+cKA+DgwiSy
wLC3PUmeq4PGE6yRI4MiAxtoib42aLsgOQ0SOpyprEVIoeXxX5hRDM98p2QhgvWy
PiGvTaSmZM1EzZTuP47ATuF29277Nr8MZQYswwTkevOVWMkolcOG2VSenfKCbjul
u9/QvptlsjUIYEUJ9JpqBrGXZl+yHYjzFkC420EvAthZA0qiyef1CsmgTpZ7h0QA
7HSYwXKRzluEwIEOgMvfhSHVnCO3ituX31+T8p/vDVM7Han9rpcaCB3kIAYya21W
KiVfGkYyRBmyMJbKhGB0r2ffD05itZqG50QchPEsY9b3ryC49iBFN8JJFw5Uuys0
GfWOCh/084ihtiyIc6zLaZnKnlpUbWuFaZTZJcRX8zklLuqz14PJR+jC5bOpJlnw
tyFUkvS4fJ9QpGQ3ext7A40vTZ4cL9JFf0Y0Cw6gQqsbLiXCMbwMST4S0uniG7Jg
EIZ4NTgRQhqZqSsRZTadk0CVzyNHuwn5lN+PAlUVsODqQdavxhM8gCfPSEeQOAcF
6QMDIqv+KU/ECMlDQszzEDSPi4AR2L+FjTZa/O8Ly+BZKLSNJ9pGs78743tyjCyX
x2Uh4vDoQ638F+Ml8TK2
=QFca
-END PGP SIGNATURE-



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

Bug#626019: libsane-perl: Proposal on how to track this down

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Jeffrey!

How much work would it be to write a C program that does the same
calls to libsane as the partly failing test in libsane-perl does? My
idea is to analyze this program with Helgrind (valgrind), in the hope
to find a race condition. If such a race condition could be
identified, this race condition could clearly be attributed to libsane
- - and hopefully being fixed easily.

With perl being involved the helgrind output is quite unreadable, as
there are a lot of warnings related to perl.

Willi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPr+6WAAoJEIy+IZx0V22Bx/YQAITS/azJFiQ8UtPEsTEMCumy
rs8allKC3whXxoF1/Pn3ZaRwyJSQM+LAyHouBAM1A/dK3AdwYzC533XzU63MvJX0
EZekvuujRdQiIUVjD7hCx8pJqUSg7cycAB/MTHQLW5MFflFa0xZCOe2X+Tsi5bWW
HJ5Y67PIUQ7KxeFK3G9+Za+u4Aqw+oVnk27wZxL3yjWFYZInCzOsBgN9+Lz51yON
C2Rqb5IBP4pl5Trf+TACFgKATK2cA/zp9ESrLzcs5F7e0ARbTeCYjfteKy6eJiZq
6E3fkCIwhYkiXa6rQSZWV76N+tmO0NeH2C6BvusICkl9RoWneJPLtqqt6UEx+rx4
OQuNUtZ018wrjZ+1rfNEYVrpx4UHYkjmkpy3PNwBHM9A6Qxfzzu1Hebpicsj/ats
liqnbvPPHKa+Z7z6ppcUjfE4SgrbDJ+C5yDWu+YOdXpllUrX1Tx9xmthI1MrbctZ
SG4uugnvdrFc2yWHyn1a1D+tt9xeEojChdj2BJcoFEZoT0RbHEZiggVR5gVSSJGR
ROdCwtIDFljhOkh/8PkuuAF0c2i8YDF9TBLk/gm9pCSYDsNVDu3A53Bi+SZh4+rY
e3R+CMaswSJWW7+JQ66VogvZe7VsvcWuLZF9J19GN7PRi0HaxnUnh04LRvBr1Z8f
y+hjIyxkNbPTfPBs59YH
=UkQR
-END PGP SIGNATURE-



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

Bug#667320: patch for pdfedit FTBFS with g++-4.7

[Willi Mann]

tag 667320 + patch
thanks

Hi!

Attached fixes the FTBFS bug on pdfedit. Please let me know whether you
would appreciate an NMU.

WM
diff --git a/src/gui/rect2Darray.h b/src/gui/rect2Darray.h
index 953865f..d9d53bb 100644
--- a/src/gui/rect2Darray.h
+++ b/src/gui/rect2Darray.h
@@ -305,7 +305,7 @@ void RectArrayT::myAppend ( const BBoxOfObjectOnPageT * item ) {
 		minY = std::min( minY, item-top() );
 		maxY = std::max( maxY, item-bottom() );
 	}
-	append( item );
+	this-append( item );
 }
 
 template typename T
@@ -461,7 +461,7 @@ void Rect2DArrayT::myAppend( BBoxOfObjectOnPageT * bbox ) {
 	if (toAppend) {
 		current = new RectArrayT();
 		current-myAppend( bbox );
-		append( current );
+		this-append( current );
 	}
 }
 

Bug#626019: hang even on amd64 with backtrace

[Willi Mann]

Hi!

I was able to reproduce the hang on amd64. Attached is a backtrace, 
unfortunately from an optimized build but maybe it gives someone a quick 
idea what's going on.


WM
#0  __lll_lock_wait_private () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
#1  0x2b8ad36223f8 in _L_lock_9627 () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x2b8ad36207e1 in *__GI___libc_free (mem=0x2b8ad3928e60) at 
malloc.c:3736
#3  0x2b8ad3b6ccd2 in XS_Sane__Device_DESTROY (my_perl=optimized out, 
cv=optimized out) at Sane.xs:17
#4  0x2b8ad2c3d54f in Perl_pp_entersub (my_perl=0x146a010) at pp_hot.c:3046
#5  0x2b8ad2bd0572 in Perl_call_sv (my_perl=0x146a010, sv=0x1675d80, 
flags=45) at perl.c:2647
#6  0x2b8ad2c43888 in S_curse (check_refcnt=1 '\001', sv=0x1624418, 
my_perl=0x146a010) at sv.c:6342
#7  Perl_sv_clear (my_perl=0x146a010, orig_sv=0x1624418) at sv.c:6073
#8  0x2b8ad2c43f72 in Perl_sv_free2 (my_perl=0x146a010, sv=0x1624418) at 
sv.c:6474
#9  0x2b8ad2c6bdb8 in Perl_leave_scope (my_perl=0x146a010, base=4) at 
scope.c:900
#10 0x2b8ad2c75d50 in Perl_pp_leaveloop (my_perl=0x146a010) at pp_ctl.c:2249
#11 0x2b8ad2c34a06 in Perl_runops_standard (my_perl=0x146a010) at run.c:41
#12 0x2b8ad2bd612a in S_run_body (oldscope=1, my_perl=0x146a010) at 
perl.c:2350
#13 perl_run (my_perl=0x146a010) at perl.c:2268
#14 0x00400ee9 in main (argc=3, argv=0x7fff667cf7e8, 
env=0x7fff667cf808) at perlmain.c:120

(gdb) bt full
#0  __lll_lock_wait_private () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97
No locals.
#1  0x2b8ad36223f8 in _L_lock_9627 () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x2b8ad36207e1 in *__GI___libc_free (mem=0x2b8ad3928e60) at 
malloc.c:3736
ignore1 = 128
ignore2 = optimized out
ignore3 = -512
ar_ptr = 0x2b8ad3928e60
p = 0x14982e0
#3  0x2b8ad3b6ccd2 in XS_Sane__Device_DESTROY (my_perl=optimized out, 
cv=optimized out) at Sane.xs:17
handle = 0x14982f0
sv = 0x161e740
sp = optimized out
ax = 1
mark = optimized out
items = optimized out
#4  0x2b8ad2c3d54f in Perl_pp_entersub (my_perl=0x146a010) at pp_hot.c:3046
markix = 0
sp = optimized out
sv = 0x1675d80
gv = 0x0
cv = 0x1675d80
cx = optimized out
gimme = 1
hasargs = optimized out
#5  0x2b8ad2bd0572 in Perl_call_sv (my_perl=0x146a010, sv=0x1675d80, 
flags=45) at perl.c:2647
sp = optimized out
myop = {op_next = 0x0, op_sibling = 0x0, op_ppaddr = 0, op_targ = 0, 
op_type = 0, op_opt = 0, op_latefree = 0, op_latefreed = 0, op_attached = 0, 
  op_spare = 0, op_flags = 65 'A', op_private = 0 '\000', op_first = 
0x0, op_other = 0x7fff667cf370}
method_op = {op_next = 0x165cbd0, op_sibling = 0x1675d80, op_ppaddr = 
0x1623f38, op_targ = 21407824, op_type = 128, op_opt = 0, op_latefree = 0, 
  op_latefreed = 1, op_attached = 0, op_spare = 5, op_flags = 70 'F', 
op_private = 1 '\001', op_first = 0x2b8ad2c43162}
oldmark = 0
retval = 0
---Type return to continue, or q return to quit---
oldscope = 5
oldcatch = 0 '\000'
ret = optimized out
oldop = 0x161d680
cur_env = {je_prev = 0x7fff667cf5d0, je_buf = {{__jmpbuf = 
{140734912852848, 6804210356706508014, 0, 21955016, 23448528, 21407872, 
-6803910496586662674, 682522875078278382}, __mask_was_saved = 
0, __saved_mask = {__val = {79, 47875266131712, 140734912853196, 0, 
  47875266131712, 47875261884042, 21405712, 206158430224, 
140734912852976, 140734912852784, 21405712, 21636752, 21407848, 23448528, 
  47875249246256, 0, je_ret = 0, je_mustcatch = 0 '\000'}
#6  0x2b8ad2c43888 in S_curse (check_refcnt=1 '\001', sv=0x1624418, 
my_perl=0x146a010) at sv.c:6342
tmpref = 0x165cbd0
destructor = 0x1675d80
sp = optimized out
stash = 0x1623f38
#7  Perl_sv_clear (my_perl=0x146a010, orig_sv=0x1624418) at sv.c:6073
stash = optimized out
type = 7
sv_type_details = optimized out
iter_sv = optimized out
next_sv = optimized out
sv = optimized out
#8  0x2b8ad2c43f72 in Perl_sv_free2 (my_perl=0x146a010, sv=0x1624418) at 
sv.c:6474
No locals.
#9  0x2b8ad2c6bdb8 in Perl_leave_scope (my_perl=0x146a010, base=4) at 
scope.c:900
uv = optimized out
type = optimized out
sv = 0x148c098
value = optimized out
gv = optimized out
av = optimized out
hv = optimized out
ptr = 0x1495cd8
str = optimized out
i = optimized out
was = 0 '\000'
---Type return to continue, or q return to quit---
#10 0x2b8ad2c75d50 in Perl_pp_leaveloop (my_perl=0x146a010) at pp_ctl.c:2249
sp = 0x146f710
cx = 0x146fb70
gimme = optimized out
newsp = 0x146f710

Bug#626019: not reproducible in mips/qemu

[Willi Mann]

Hi!

I tried to reproduce the problem within qemu (qemu-system-mips, kernel 
3.2.0-1-4kc-malta), but the tests are passed fine.


WM



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

Bug#656629: enigmail: OpenPGP menu does not appear in Icedove 8.0.2

[Willi Mann]

severity 656629 important
thanks

Hi!

On 2012-01-20 14:33, Julien Patriarca wrote:
 Package: enigmail
 Version: 2:1.3.4-1
 Severity: grave
 Justification: renders package unusable
 
 Dear Maintainer,
 
 After installing enigmail the main menu does not appear in Icedove 8.0.2.
 But it is present when I write an email. An XML error appears when clicking 
 on key management inside this menu.
 The decrypting functions don't work either, and I am not prompted when 
 receiving a signed email.

The problem does not occur on all installations, so lowering severity.
As already discussed, in Bug#656306, the problem is locale-dependent.
You should be able to work around the problem by starting icedove with
LANG=C in the environment.

WM



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

Bug#654829: enigmail: Enigmail activates but doesn't work

[Willi Mann]

On 2012-01-17 11:28, Raphael Rigo wrote:
 Package: enigmail
 Version: 2:1.3.4-1
 Followup-For: Bug #654829
 
 Hello,
 the new version of enigmail is effectively active, but when trying to
 access the preferences, a chrome error is displayed :
 
 XML Parsing Error: undefined entity
 Location: chrome://enigmail/content/pref-enigmail.xul
 Line Number 111, Column 20:
 descriptionenigmail.keepCryptoSettingsForReply.tooltip;/description
 
 This renders the plugin unusable, all functionalities seem disabled.

I cannot reproduce this (the preference window does work for me, on
x86), but please file a separate bug report, otherwise I very likely
miss your report.

WM



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

Bug#654829: enigmail: Menu not present and verifying decrypting not working

[Willi Mann]

On 2012-01-17 12:05, Julien Patriarca wrote:
 Package: enigmail
 Version: 2:1.3.4-1
 Followup-For: Bug #654829
 
 Dear Maintainer,
 
 The enigmail package is not working properly in Icedove 8.0.2.
 Indeed the menu does not appear in the main toolbar, and the verifying and
 decrypting functions do not work. I mean when I receive a signed-message,
 nothing is being displayed about the signature.


I cannot reproduce this (the menu appears and the verifying and
decrypting functions do work for me, on x86), but please file a separate
bug report, otherwise I will very likely miss your report.

WM



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

Bug#634595: courier: FTBFS: umask error

[Willi Mann]

tag 634595 + patch
thanks

Hi Racke!

In order to fix this problem, I propose to apply attached patch. I hope
my assumption is correct that only the install target needs the 022
umask - it builds for me, but I did not do a before/after analysis of
the file permissions in the packages built.

WM


 Relevant part:
  fakeroot debian/rules clean
 dh_testdir
 if [ ! -x /usr/bin/openssl ]; then \
  echo You need to install openssl first; \
  exit 1; \
  fi
 if [ `umask` != 0022 ]; then echo You need to set umask to 022 in order 
 to compile/build courier; exit 1; fi
 You need to set umask to 022 in order to compile/build courier
 make: *** [check] Error 1

diff --git a/debian/rules b/debian/rules
index 7879771..8b21188 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,8 +63,6 @@ check:
 		exit 1; \
 	fi
 
-# check umask
-	if [ `umask` != 0022 ]; then echo You need to set umask to 022 in order to compile/build courier; exit 1; fi
 	chmod +x debian/fixlinks
 	chmod +x debian/courier_perms
 	chmod +x debian/correctpermissions.pl
@@ -93,7 +91,10 @@ clean: check
 #can be removed later
 	rm -f debian/permissions
 
-install: check stamp-build
+install:
+	umask 0022; $(MAKE) -f debian/rules install.real
+
+install.real: check stamp-build
 	dh_testroot
 	dh_clean -k
 	dh_installdirs
@@ -346,4 +347,4 @@ binary-arch: stamp-build stamp-install
 
 binary: binary-indep binary-arch
 
-.PHONY: check build clean binary-indep binary-arch binary install
+.PHONY: check build clean binary-indep binary-arch binary install install.real

Bug#627340: enigmail: does not work with icedove 3.1.10

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

package enigmail
severity 627340 important
tag 627340  + unreproducible moreinfo
thanks

Hi!

 since icedove 3.1.10-1 enigmail does not work anymore, but it reports itself 
 as
 compatible.

I can't reproduce this. How does not work anymore manifest? Is there
no source at all from the enigmail mail extension in the icedove
windows? Or is the problem limited to sending/receiving/whatever? Please
be more specific.

WM
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJN1WSJAAoJEIy+IZx0V22B0RoP/3DH2mfG7m5VzvOWlIVIJ04D
qZYkiEcJWl8/OTABnE7MLmHPf1Tv3mr0i396FCRoMAsjfu99WSWbqOAjihXU4pLG
u1hCna6/sj3wqSEBDQ4oIjRXoQ3YUccIcTDpLmJHAOF6JZkhwkoAIFDA2hHfxfB/
sWsJH/KUc/+Uph5N+wv78wnCSTTP9TUhiqlKPIwXTQgi8z9QpC/PZiqWuq34bneV
aNL9UQ7nv2PMaiZEfeOkduwveHF2uGvaguCHvkNaNHAXsoM3QnDM9iyAAJWeg0oQ
o3kxGmDLE3qPpzcphSHU8MZsF4ny92tH3nVNPyqw9N/itT+dmD9R/7bJvjdExXg+
Ps7G6b/oLeo1tAAN7t9szpHGWh21xIzO1h1RnCidzRQmjSIlINXBtTSQRDtMOkgG
4IJKHPuSPOov6U3m73y8ppLq1gZD3GAs8IpYZhoMcCw0qhUfjX8HWcvd7kEEvZMz
C26FOGQ8AZa4PT8SbDc1ZGz56e5GRClhvtxKCE7wk5FmramnJx3MNtCisgKq4WrR
wCQ1yZ1kYYFbPYF921sseAXiXkngIUqwVY9aIhMC4tWOenfRkWKv08RHGntUYRs9
UHXn+yiviTnn4h+pf69DrXWOQ60PsW7lma1xPvBSNIEXLqIEcsCUwFUveA98+c9/
VDIcmJVBTVT8HEN2FWjD
=C6Mw
-END PGP SIGNATURE-



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

Bug#615995: CVE-2011-1018

[Willi Mann]

 Please see https://bugzilla.redhat.com/show_bug.cgi?id=680237
 for references.
 
 This is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1018

Thanks for the report. I'll ask my sponsor to upload

http://pkg-logwatch.alioth.debian.org/apt/pool/main/l/logwatch/logwatch_7.3.6.cvs20090906-2.dsc

to unstable.

I know that a new upstream version is available, but this takes more
time for preparation.

Moritz, will you prepare the uploads for stable and oldstable? This is
the first time one of my packages is involved in a security issue.

Willi





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

Bug#584327: Bug #584327: is it an issue?

[Willi Mann]

Am 2010-11-14 01:59, schrieb Luca Falavigna:
 I wonder whether this is still an issue, given that enigmail now builds
 on mipsel again, see related log:
 
 https://buildd.debian.org/fetch.cgi?pkg=enigmailarch=mipselver=2%3A1.0.1-5stamp=1278109432file=logas=raw
 

I builds on mipsel because we switched to another rdf query
implementation in mozilla-devscripts. m-d did the SIGBUS-causing query
when building enigmail on mipsel. I already posted this on Jun 10, but
my message was probably to cryptic.

WM



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

Bug#584327: Bug #584327: is it an issue?

[Willi Mann]

Am 2010-11-14 13:30, schrieb Nacho Barrientos Arias:
 On Sun, Nov 14, 2010 at 01:59:31AM +0100, Luca Falavigna wrote:
 I wonder whether this is still an issue, given that enigmail now builds
 on mipsel again, see related log:
 
 It builds fine because mozilla-devscripts (a build-dep of enigmail) no
 longer depends on this package.
 
 Rdflib 3.0.0 is on its way (I promise, he) so, as it does not ship C
 extensions, it will be impossible to reproduce this problem.
 
 Willi, do you agree on closing this bug? 

Yes, I'm fine with that as it no longer touches one of my packages.
Additionally, if there's still a bug, it's in gcc.

WM



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

Bug#586860: icedove 3.0.5-1 breaks enigmail build

[Willi Mann]

 char16_t comes from C++0x[1], so you need to add '-std=gnu++0x' to your
 CXXFLAGS. A quick build of enigmail by myself works find.

Thanks for the information and for testing the enigmail build. A fixed
package will be uploaded shortly.

WM



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

Bug#586860: icedove 3.0.5-1 breaks enigmail build (was: Bug#586860: enigmail: FTBFS: error: 'char16_t' was not declared in this scope)

[Willi Mann]

clone 586860 -1
reassign -1 icedove-devel
thanks

Hi!

Icedove version 3.0.5-1 breaks the build of enigmail: It defines
HAVE_CPP_CHAR16_T in /usr/lib/icedove-devel/xpcom-config.h.

Later in /usr/lib/icedove-devel/include/nsStringAPI.h:1055, it chacks
the size of char16_t, which seems not to be defined, at least on i386
and amd64.

I'm cloning the bug, not reassigning it, because rebuild testers might
just file a new bug report after I reassign.

WM

Source: enigmail
Version: 2:1.0.1-3
Severity: serious

Hi,

enigmail FTBFS on sid.
I confirmed amd64, i386 by pbuilder.
-
c++ -o nsPipeTransport.o -c -I../../../../dist/system_wrappers
-include /tmp/buildd/enigmail-1.0.1/config/gcc_hidden.h
-DMOZILLA_MAJOR_VERSION=1 -DMOZILLA_MINOR_VERSION=9
-DOSTYPE=\Linux2.6\ -DOSARCH=Linux
-I/tmp/buildd/enigmail-1.0.1/extensions/enigmail/ipc/src/../build
-I/tmp/buildd/enigmail-1.0.1/extensions/enigmail/ipc/src -I.
-I../../../../dist/include -I../../../../dist/include/nsprpub
-I/usr/lib/icedove-devel/include
-I/usr/lib/icedove-devel/include/nsprpub -I/usr/include/nspr
-I/usr/lib/icedove-devel/include/nss -fPIC   -fno-rtti
-fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align
-Wno-invalid-offsetof -Wno-long-long -pedantic -g -O2
-fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED
-Os -freorder-blocks -fno-reorder-functions-DMOZILLA_CLIENT
-include ../../../../mozilla-config.h -Wp,-MD,.deps/nsPipeTransport.pp
nsPipeTransport.cpp
In file included from /usr/lib/icedove-devel/include/nsStringGlue.h:52,
 from /usr/lib/icedove-devel/include/nsThreadUtils.h:47,
 from ipc.h:45,
 from nsPipeTransport.cpp:38:
/usr/lib/icedove-devel/include/nsStringAPI.h:1055: error: 'char16_t'
was not declared in this scope
nsPipeTransport.h: In constructor 'nsPipeTransport::nsPipeTransport()':
nsPipeTransport.h:159: warning:
'nsPipeTransport::mPipeTransportWriter' will be initialized after
nsPipeTransport.h:144: warning:   'nsCString_external
nsPipeTransport::mExecBuf'
nsPipeTransport.cpp:95: warning:   when initialized here
make[8]: *** [nsPipeTransport.o] Error 1
-

Could you check your pakcage?

Best regards,
 Nobuhiro







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

Bug#584358: pending

[Willi Mann]

tag 584358 + pending
thanks

I fixed packege is ready and waiting to be uploaded by Daniel Baumann.
It is available from

http://wserver.wm1.at/~willi/debian/various/pool/main/s/sqwebmail-de/



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

Bug#584327: patch

[Willi Mann]

Hi!

The maintainer of mozilla-devscripts today uploaded a new revision that
uses python-librdf instead of python-rdflib (I wrote the patches). So
uploading a new upstream version of python-rdflib no longer conflicts
with mozilla-devscripts requirements.

WM



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

Bug#584327: patch

[Willi Mann]

Hi!

 Thanks.
 
 RDFLib 3.0.0 was recently released. Thus, before uploading a patched
 debian/rules, I'd like to test whether this issue is reproducible with
 the new version as well. I'm preparing a package, it would be great if
 you could test it on your mipsel virtual machine. Give me some time,
 you will have it in your inbox shortly.

Yes, of course.

 Anyway, this is obviously a workaround and, as you pointed out before,
 we need to generate a minimal test case to report a bug
 against gcc.

The problem is that it seems impossible to really make a short test
case. The parser contains many if-blocks with the condition
if(self-verbose). I removed them because self-verbose is always false
in our case. The bug no longer occurred. Then I did a binary search on
the number of blocks I can remove before the bug disappears. I now have
two versions of the parser that only differ in two lines, but one
exposing the problem, the other not.

My guess is that there is some wrong overflow detection in gcc when
relative addressing is used (that would explain why it only occurs on
long functions). However, I need to further investigate this, and even
if I can find the root of the problem, it will take some time that a fix
is made and included in Debian's toolchain.

WM



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

Bug#584327: patch

[Willi Mann]

Hi!

I'm CCing the maintainers of mozilla-devscripts, as they should decide
how to proceed.

Am 2010-06-07 13:00, schrieb Nacho Barrientos Arias:
 On Mon, Jun 7, 2010 at 10:34 AM, Willi Mann wi...@wm1.at wrote:
 Thanks.

 RDFLib 3.0.0 was recently released. Thus, before uploading a patched
 debian/rules, I'd like to test whether this issue is reproducible with
 the new version as well. I'm preparing a package, it would be great if
 you could test it on your mipsel virtual machine. Give me some time,
 you will have it in your inbox shortly.

 Yes, of course.
 
 The package is almost ready but we're in serious trouble now.
 
 RDFLib 3.0.0 does not ship C extensions so this bug is not
 reproducible any longer.
 
 BUT we have a bigger problem now: support for graph querying using
 SPARQL has been dropped. This means that your test case won't work
 and, even worse, that enigmail installation (and maybe others) will
 fail now on every architecture (*sigh*).

Applies to all packages using /usr/bin/install-xpi, an that's quite a lot.

 http://paste.debian.net/76438/
 
 Look at this: http://code.google.com/p/rdflib/wiki/IntroSparql
 
 In short, Rdfextras must be packaged for Debian if you want RDFLib to
 dispatch SPARQL queries. Any volunteers?

How many users rely on the extension? In case the number is low, it's
probably better to work around the problem.

mozilla-devscripts maintainers, would it be possible to use
python-librdf instead of python-rdflib to do the queries on install.rdf?

WM



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

Bug#584358: fix

[Willi Mann]

I'll fix this bug next weekend, maybe earlier.

Note to release managers: As long as courier 0.65.0 keeps out of
testing, testing is not affected.

WM



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

Bug#584784: also applies to unstable

[Willi Mann]

Am 2010-06-07 03:44, schrieb Ben Hutchings:
 On Sun, 2010-06-06 at 23:18 +0200, Willi Mann wrote:
 Kernel panic - not syncing: To avoid data corruption io_map_base MUST
 be set with multiple PCI domains.

 has been applied on all PCI MIPS systems since Linux 2.6.24.  Are you
 quite sure that this was introduced by the kernel upgrade and not a qemu
 upgrade.

 Yes, I didn't change the qemu version, it's really only the kernel that
 changed.

 Attached is the dmesg output of the working kernel, version 2.6.32-9.
 
 OK, it looks like this is due to an botched switch from IDE to libata
 drivers on MIPS.  The qemu emulated HD controller is now being handled
 by the ide-generic driver whereas it should have been switched from piix
 to ata_piix, and ide-generic triggers this panic for reasons I don't
 fully understand.
 
 This will get fixed, but not immediately.

OK. As long as it gets fixed before the release... Should we notify the
d-i people so that they can put a note on the errata page?

Though I wonder why the BTS did not fully process my found command. It
still only marks the version in experimental as affected.

WM



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

Bug#584784: /boot/vmlinux-2.6.34-1-4kc-malta: no longer boots in qemu

[Willi Mann]

Package: linux-2.6
Version: 2.6.34-1~experimental.1
Severity: grave
File: /boot/vmlinux-2.6.34-1-4kc-malta

This kernel no longer boots in qemu 0.12.4+dfsg-1 (boot messages attached).
The last version that successfully booted is 2.6.32-9. I haven't yet tested 
the current unstable kernel.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
system type : MIPS Malta
cpu model   : MIPS 24Kc V0.0  FPU V0.0

** PCI devices:
00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. 
GT-64120/64120A/64121A System Controller [11ab:4620] (rev 10)
Subsystem: Qumranet, Inc. Device [1af4:1100]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Interrupt: pin A routed to IRQ 0
Region 0: Memory at unassigned (32-bit, prefetchable) [disabled]
Region 1: Memory at 0100 (32-bit, prefetchable) [disabled] 
[size=16M]
Region 2: Memory at ignored (32-bit, non-prefetchable) [disabled]
Region 3: Memory at ignored (32-bit, non-prefetchable) [disabled]
Region 4: Memory at ignored (32-bit, non-prefetchable) [disabled]
Region 5: I/O ports at ignored [disabled]

00:0a.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110]
Subsystem: Qumranet, Inc. Device [1af4:1100]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0

00:0a.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE 
[8086:7111] (prog-if 80 [Master])
Subsystem: Qumranet, Inc. Device [1af4:1100]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) 
[size=8]
Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) 
[size=1]
Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) 
[size=8]
Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) 
[size=1]
Region 4: I/O ports at 1040 [size=16]
Kernel driver in use: PIIX_IDE

00:0a.2 USB Controller [0c03]: Intel Corporation 82371AB/EB/MB PIIX4 USB 
[8086:7112] (rev 01) (prog-if 00 [UHCI])
Subsystem: Qumranet, Inc. Device [1af4:1100]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 11
Region 4: I/O ports at 1000 [size=32]
Kernel driver in use: uhci_hcd

00:0a.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] 
(rev 03)
Subsystem: Qumranet, Inc. Qemu virtual machine [1af4:1100]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Interrupt: pin A routed to IRQ 0
Kernel driver in use: piix4_smbus

00:0b.0 Ethernet controller [0200]: Advanced Micro Devices [AMD] 79c970 
[PCnet32 LANCE] [1022:2000] (rev 10)
Subsystem: Qumranet, Inc. Device [1af4:1100]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0 (1500ns min, 63750ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 1020 [size=32]
Region 1: Memory at 12011000 (32-bit, non-prefetchable) [size=32]
Kernel driver in use: pcnet32

00:12.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] 
(prog-if 00 [VGA controller])
Subsystem: Qumranet, Inc. Device [1af4:1100]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Region 0: Memory at 1000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at 1201 (32-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at 1200 [disabled] [size=64K]
Kernel driver in use: cirrusfb


** USB devices:
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')

Bug#584784: also applies to unstable

[Willi Mann]

found 584784 2.6.32-15
thanks

Hi!

Unfortunately, this bug also applies to unstable, only current testing
kernel is unaffected.

WM



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

Bug#584327: patch

[Willi Mann]

tag 584327 + patch
thanks

Hi!

Attached is a patch for debian/rules that reduces the optimization level
to 1 for mipsel and mips, which fixes the problem at least on mipsel.
(tested, not tested on mips). I would be nice if you could upload rdflib
with this patch soon.

thanks
Willi
diff -u rdflib-2.4.2/debian/rules rdflib-2.4.2/debian/rules
--- rdflib-2.4.2/debian/rules
+++ rdflib-2.4.2/debian/rules
@@ -4,6 +4,13 @@
 
 include /usr/share/quilt/quilt.make
 
+DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
+
+ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
+   CFLAGS:=-O1
+endif
+
+
 configure: configure-stamp
 configure-stamp: patch
dh_testdir

Bug#584784: also applies to unstable

[Willi Mann]

 Kernel panic - not syncing: To avoid data corruption io_map_base MUST
 be set with multiple PCI domains.
 
 has been applied on all PCI MIPS systems since Linux 2.6.24.  Are you
 quite sure that this was introduced by the kernel upgrade and not a qemu
 upgrade.

Yes, I didn't change the qemu version, it's really only the kernel that
changed.

Attached is the dmesg output of the working kernel, version 2.6.32-9.

WM
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.32-3-4kc-malta (Debian 2.6.32-9) 
(m...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 Thu Feb 25 08:38:29 
UTC 2010
[0.00] 
[0.00] LINUX started...
[0.00] bootconsole [early0] enabled
[0.00] CPU revision is: 00019300 (MIPS 24Kc)
[0.00] FPU revision is: 
[0.00] registering PCI controller with io_map_base unset
[0.00] Determined physical RAM map:
[0.00]  memory: 1000 @  (reserved)
[0.00]  memory: 000ef000 @ 1000 (ROM data)
[0.00]  memory: 005b1000 @ 000f (reserved)
[0.00]  memory: 0f95f000 @ 006a1000 (usable)
[0.00] Wasting 54304 bytes for tracking 1697 unused pages
[0.00] Initrd not found or empty - disabling initrd
[0.00] Zone PFN ranges:
[0.00]   DMA  0x - 0x1000
[0.00]   Normal   0x1000 - 0x0001
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[1] active PFN ranges
[0.00] 0: 0x - 0x0001
[0.00] On node 0 totalpages: 65536
[0.00] free_area_init_node: node 0, pgdat 805ef310, node_mem_map 
8100
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 4064 pages, LIFO batch:0
[0.00]   Normal zone: 480 pages used for memmap
[0.00]   Normal zone: 60960 pages, LIFO batch:15
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 65024
[0.00] Kernel command line: root=/dev/hda1 console=ttyS0
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Primary instruction cache 2kB, VIPT, 2-way, linesize 16 bytes.
[0.00] Primary data cache 2kB, 2-way, VIPT, no aliases, linesize 16 
bytes
[0.00] Writing ErrCtl register=
[0.00] Readback ErrCtl register=
[0.00] Memory: 252864k/255356k available (3985k kernel code, 2252k 
reserved, 1085k data, 208k init, 0k highmem)
[0.00] SLUB: Genslabs=7, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, 
Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00] NR_IRQS:256
[0.00] CPU frequency 200.00 MHz
[0.00] Console: colour dummy device 80x25
[0.008000] Calibrating delay loop... 475.13 BogoMIPS (lpj=950272)
[0.096000] Security Framework initialized
[0.096000] SELinux:  Disabled at boot.
[0.096000] Mount-cache hash table entries: 512
[0.108000] Initializing cgroup subsys ns
[0.108000] Initializing cgroup subsys cpuacct
[0.108000] Initializing cgroup subsys devices
[0.108000] Initializing cgroup subsys freezer
[0.108000] Initializing cgroup subsys net_cls
[0.124000] devtmpfs: initialized
[0.132000] regulator: core version 0.5
[0.136000] NET: Registered protocol family 16
[0.156000] bio: create slab bio-0 at 0
[0.16] vgaarb: loaded
[0.164000] SCSI subsystem initialized
[0.164000] libata version 3.00 loaded.
[0.168000] pci :00:00.0: reg 14 32bit mmio pref: [0x100-0x1ff]
[0.168000] pci :00:0a.1: reg 20 io port: [0x00-0x0f]
[0.168000] pci :00:0a.2: reg 20 io port: [0x00-0x1f]
[0.168000] pci :00:0a.3: BAR 14: address space collision on of bridge 
[0x1100-0x110f]
[0.168000] pci :00:0a.3: quirk: region 1100-110f claimed by PIIX4 SMB
[0.168000] pci :00:0b.0: reg 10 io port: [0x00-0x1f]
[0.168000] pci :00:0b.0: reg 14 32bit mmio: [0x00-0x1f]
[0.168000] pci :00:12.0: reg 10 32bit mmio pref: [0x00-0x1ff]
[0.172000] pci :00:12.0: reg 14 32bit mmio: [0x00-0x000fff]
[0.172000] pci :00:12.0: reg 30 32bit mmio pref: [0x00-0x00]
[0.172000] vgaarb: device added: 
PCI::00:12.0,decodes=io+mem,owns=none,locks=none
[0.176000] pci :00:0a.3: BAR 14: bogus alignment [0x1100-0x110f] flags 
0x100
[0.18] Switching to clocksource MIPS
[0.208000] NET: Registered protocol family 2
[0.208000] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.216000] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[0.216000] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[0.216000] TCP: Hash 

Bug#584327: python-rdflib

[Willi Mann]

Hi!

 Thanks for reporting. At the first glance, these are my (probably
 wrong) thoughts:
 
 As expected, it works well here (amd64, python2.6, rdflib 2.4.2-1+b1).

Yes, otherwise the enigmail build would fail on more architectures.

 Your debug steps are clear, but I'm not really sure if python-rdflib
 is the one to blame here. Bus error looks more like an internal
 Python interpreter malfunction than a problem in the library itself,
 maybe caused by porting issues.

That's possible but less likely because there is (and was, AFAIK) no bug
report against the python package involving specifically the mips
architecture. As a bug in the interpreter would very likely also affect
other builds, I think it is safe to say the interpreter is OK.

 OTOH, given it fails calling query() (SPARQL query parsing is
 involved), the problem may be in the C extension (SPARQLParserc.so).
 As a starting point, I should investigate if SIGBUS is raised either
 by a problem in the extension or is Python-related.
 
 If you don't mind, I've a couple of questions for you.
 
 Perhaps this is a dumb question but, is Qemu MIPS emulation reliable
 enough to use it for debugging purposes? Have you tried it in real
 hardware? Does it fail anyway?

I don't have shell access to real hardware, but the bus error was first
seen in the build log of enigmail, and the builds are done on real
hardware. So qemu just behaves as some real hardware. And a qemu armel
image also helped me to debug a another build issue. So I think the
results can really be trusted.

 Do you know about any other python library with C extensions
 experiencing the same behavior in your Qemu image? Or maybe crashing
 with other Python/OS/whatever internal errors?

No, I only came over it because the failing enigmail build. However,
I've asked on the debian-mips mailing list to do test a build of
enigmail (that was before I set up the qemu image). In the mean time,
someone answered and told me that it also failed on his box, but with
Segmentation fault. As he uses kernel 2.6.34, it's possible that it's
just the signal that changed (SIGBUS and SIGSEGV are both related to
memory access)

And yes, I would suspect the C extension to be the culprit, but we need
a way to prove this.

I'm currently tring to rebuild rdflib in the emulator. My test case
succeeds when I compile with DEB_BUILD_OPTIONS=noopt nostrip, so I'm
now trying with DEB_BUILD_OPTIONS unset. Maybe the bug is caused by a
bug in an old gcc version and gcc is now fixed.

WM





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

Bug#584327: more information

[Willi Mann]

It seems that the bug is caused by a gcc bug that is only triggered when
compiling with optimization. So a workaround would be to build
python-rdflib with -O0 on mipsel (and possibly mips, I'm still waiting
for the first build logs of enigmail to be published).

Of course it would be better if we could produce a simple test case for
a bug report against gcc.

WM



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

Bug#569804: NMU prepared

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 2010-05-27 20:52, schrieb Alexander Sack:
 On Thu, May 27, 2010 at 08:32:00PM +0200, Torsten Werner wrote:
 Hi,

 On Thu, May 27, 2010 at 8:25 PM, Alexander Sack a...@jwsdot.com wrote:
 Well, the sponsoring is the blocker for me too ;)

 I am willing to sponsor uploads of enigmail.

 @Willi: may you provide a debdiff file, please?
 
 
 Thanks Thorsten, please ensure this is not an NMU and that Willi is addedd to 
 the
 Uploaders; also its ok for me to add the DM-Uploads-Allowed tag in 
 debian/control ...
 but we can also that in a later upload.

Hi Alexander, Hi Thorsten!

I've now added myself to Uploaders. The interdiff between the Ubuntu
version and my version is attached. Most content of the interdiff is the
file debian/clean, which lists files that are not properly removed when
the clean target is executed. It seems that the Makefiles' clean target
is not recursively called, only the clean target in the package's root
is executed. I think we can fix this in a later upload. debian/clean
should suffice for now, I've tested this on i386 and amd64. (I first
thought that the problem is caused by the tarball, but this is not true)

I've also added fixes for all but 1 lintian warnings (see changelog).
The missing fix is the fix for the missing copyright holder line.

http://wserver.wm1.at/~willi/debian/various/pool/main/e/enigmail/

I consider the package now ready for upload. Thorsten, please review my
changes and upload the package if you are happy with my changes.

Willi Mann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv/y1AACgkQoJXkHZOJUgttHQCbBJL01XL3gtAL4uqibzGX4wFl
YuMAoIHZv4TE9dcYeqFxXDptk5av7EHF
=WkuE
-END PGP SIGNATURE-


enigmail-ubuntu-debian.diff.gz
Description: GNU Zip compressed data

Bug#569804: NMU prepared

[Willi Mann]

Hi!

As Alexander Sack hasn't even answered any public request to do an
enigmail upload, I've prepared an NMU based in asac's Ubuntu package. It
is available from:

http://wserver.wm1.at/~willi/debian/various/pool/main/e/enigmail/

Alexander, in identi,ca you posted that you are currently on holidays.
However, you haven't answered requests about an upload even before.
Please tell us whether you want to veto the NMU as soon as possible.

Thorsten Werner, would you be willing to sponsor the upload? My proposal
is to do an NMU to DELAYED/7 once the package is considered ready to
give Alexander time to react.

As this is a new upstream NMU, it should receive some more review, and
it needs some real testing, for which I haven't had time so far. That's
why the version number currently contains ~wm1.

Alexander, I'd be willing to take this package over if you no longer
want to maintain enigmail in Debian and someone promises to sponsor my
uploads.

Willi



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

Bug#569804: enigmail in Debian

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

Could you please post a status update on what the remaining issues for
an enigmail upload to unstable are? If you lack the time to handle this
currently, please say so. I'm sure some helping hands can jump in to
make enigmail fit for squeeze.

Greetings from Salzburg
Willi Mann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv35ywACgkQoJXkHZOJUgu+UgCeI+upBWq/rF9h+rSYXQcfGsiK
sQAAn3tppDRLCIMYjb23uC7HYGdPr2Fb
=aa9V
-END PGP SIGNATURE-



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

Bug#577283: audacious: error on upgrade 2.1 - 2.3 (file conflict)

[Willi Mann]

Package: audacious
Version: 2.1-1+b1
Severity: serious
Justification: Policy 7.6.1

When installing audacious from experimental, I get the following error message 
(Sorry for the German messages):


Entpacke Ersatz für audacious-plugins ...
Ersetze die Dateien im alten Paket audacious-plugins-extra ...
dpkg: Fehler beim Bearbeiten von 
/var/cache/apt/archives/audacious-plugins_2.3-1_i386.deb (--unpack):
 Versuche, »/usr/share/audacious/Skins/Classic/shufrep.png« zu überschreiben, 
welches auch in Paket audacious 0:2.1-1+b1 ist
dpkg-deb: Unterprozess paste mit Signal (Datenübergabe unterbrochen (broken 
pipe)) getötet
Verarbeite Trigger für man-db ...
Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/audacious-plugins_2.3-1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)Tags: experimental

So /usr/share/audacious/Skins/Classic/shufrep.png moved to audacious to 
audacious-plugins. I guess a Replaces: audacious ( 2.3-1) is missing.



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

Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages audacious depends on:
ii  audacious-plugins 2.1-1.1Base plugins for audacious
ii  dbus  1.2.24-1   simple interprocess messaging syst
ii  dbus-x11  1.2.24-1   simple interprocess messaging syst
ii  gtk2-engines-pixbuf   2.18.9-2   Pixbuf-based theme for GTK+ 2.x
ii  libatk1.0-0   1.28.0-1   The ATK accessibility toolkit
ii  libaudclient2 2.1-1+b1   audacious dbus remote control libr
ii  libaudcore1   2.1-1+b1   audacious core engine library
ii  libaudid3tag2 2.1-1+b1   audacious id3 tag manipulation lib
ii  libaudutil1   2.1-1+b1   audacious utility library
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib
ii  libcairo2 1.8.10-3   The Cairo 2D vector graphics libra
ii  libdbus-1-3   1.2.24-1   simple interprocess messaging syst
ii  libdbus-glib-1-2  0.84-1 simple interprocess messaging syst
ii  libfontconfig12.8.0-2generic font configuration library
ii  libfreetype6  2.3.11-1   FreeType 2 font engine, shared lib
pn  libglib2.0-0  none (no description available)
ii  libgtk2.0-0   2.18.9-2   The GTK+ graphical user interface 
ii  libice6   2:1.0.6-1  X11 Inter-Client Exchange library
ii  libmcs1   0.7.1-1Abstraction library to store confi
ii  libmowgli10.6.1-1a high performance development fra
ii  libpango1.0-0 1.26.2-2   Layout and rendering of internatio
ii  libsad2   2.1-1+b1   audacious scale and dither library
ii  libsamplerate00.1.7-3Audio sample rate conversion libra
ii  libsm62:1.1.1-1  X11 Session Management library

Versions of packages audacious recommends:
ii  audacious-plugins-extra   2.1-1.1Various extra plugins for audaciou
ii  unzip 6.0-4  De-archiver for .zip files

audacious suggests no packages.

-- no debconf information



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

Bug#547280: Bug #547280: heimdal, rfc 3454, rfc 3492

[Willi Mann]

Hi Jelmer!

 On Mon, 2009-12-28 at 15:09 +0100, Willi Mann wrote:
 Samba 4 currently contains the full rfc3454.txt, while the debian
 heimdal package only contains the tables. Could samba upstream also
 switch to the tables only rfc3454.txt, in order to resolve this RC bug?

 Can you explain why just including the tables is a valid workaround? As
 far as I can tell from the copyright notice in the RFC, derivative works
 still need to keep the license and include the copyright notice.

I'm not a lawyer, I only read that in the bug report. I've just googled
for some relevant mails and found

http://lists.debian.org/debian-devel/2008/06/msg00233.html

The follow-up by Simon Josefsson is also interesting.

WM



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

Bug#547280: Bug #547280: heimdal, rfc 3454, rfc 3492

[Willi Mann]

Dear Jelmer!

Samba 4 currently contains the full rfc3454.txt, while the debian
heimdal package only contains the tables. Could samba upstream also
switch to the tables only rfc3454.txt, in order to resolve this RC bug?

RFC 3492 is not a problem as it's considered free according to

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489692

WM



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

Bug#562068: hald-probe-input segfaults on hal restart

[Willi Mann]

Package: hal
Version: 0.5.14-1
Severity: grave
Justification: renders package unusable

When /etc/init.d/hal restart is executed - it happened first to me on today's
upgrade - I get the following backtrace (signal 6, aborted):


#0  0xb76f2424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb75408e0 in *__GI_raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = value optimized out
pid = -1218080780
selftid = 23146
#2  0xb7543e15 in *__GI_abort () at abort.c:88
act = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, 
sa_mask = {__val = {15, 3216395664, 3076636327, 
  3077636708, 0, 3216395804, 134515137, 0, 134513276, 3, 449, 
134513824, 3, 3216395664, 4, 3216395732, 3076380203, 
  0, 41, 3076886516, 4, 2, 3216395848, 3076499512, 2, 3216395732, 
4, 0, 3076763505, 3076763501, 3076759036, 
  3076759010}}, sa_flags = -1218198869, sa_restorer = 0xb763c2a7}
sigs = {__val = {32, 0 repeats 31 times}}
#3  0xb75776c5 in __libc_message (do_abort=2, fmt=0xb763e0e8 *** glibc 
detected *** %s: %s: 0x%s ***\n)
at ../sysdeps/unix/sysv/linux/libc_fatal.c:173
ap = 0xbfb654b8 +\254c\267
fd = 2
on_2 = value optimized out
list = value optimized out
nlist = 7
cp = value optimized out
written = 6
#4  0xb7581824 in malloc_printerr (action=2, str=0xb763ac2b free(): invalid 
pointer, ptr=0xb7659ce0) at malloc.c:6239
buf = b7659ce0
cp = 0x5a6a Address 0x5a6a out of bounds
#5  0xb75830b3 in _int_free (av=0xb765a3c0, p=0xb7659cd8) at malloc.c:4772
size = 0
nextchunk = 0xb7700f7b
nextsize = 3077512360
prevsize = value optimized out
bck = value optimized out
fwd = value optimized out
errstr = 0xb763ac2b free(): invalid pointer
__func__ = _int_free
#6  0xb75860ad in *__GI___libc_free (mem=0xb7659ce0) at malloc.c:3738
ar_ptr = 0xb765a3c0
p = 0x6
#7  0xb76a74f3 in dbus_free (memory=0xb7659ce0) at dbus-memory.c:644
No locals.
#8  0xb768aae1 in dbus_error_free (error=0xbfb655b8) at dbus-errors.c:217
real = 0xbfb655b8
__FUNCTION__ = dbus_error_free
#9  0x08048cda in main (argc=value optimized out, argv=value optimized out) 
at probe-input.c:124
fd = -1
ret = 1
udi = 0xb7659324 \340\234e\267
device_file = 0x804a540 
T\244\004\bp\006q\267pkp\267\026\210\004\b\210\004\b6\210\004\bF\210\004\bV\210\004\bf\210\004\bv\210\004\b\206\210\004\bpKT\267\246\210\004\b\266\210\004\bv\255h\267\326\210\004\bp\312R\267\366\210\004\b\006\211\004\b\026\211\004\b\211\004\b6\211\004\bF\211\004\br\252h\267f\211\004\bv\211\004\b\206\211\004\b\226\211\004\b
button_type = 0x0
sw = 134517337
ctx = 0x0
error = {name = 0xb7659ce0 , message = 0xb7658ff4 |-\024, dummy1 = 
0, dummy2 = 0, dummy3 = 0, dummy4 = 0, 
  dummy5 = 0, padding1 = 0x804a540}
bitmask = {0}
__FUNCTION__ = main


Note that the SEGFAULT is not reproduceable in every hal restart. 

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

Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages hal depends on:
ii  adduser  3.111   add and remove users and groups
ii  dbus 1.2.16-2simple interprocess messaging syst
ii  hal-info 20091130-1  Hardware Abstraction Layer - fdi f
ii  libblkid12.16.2-0block device id library
ii  libc62.10.2-2GNU C Library: Shared libraries
ii  libdbus-1-3  1.2.16-2simple interprocess messaging syst
ii  libdbus-glib-1-2 0.82-2  simple interprocess messaging syst
ii  libexpat12.0.1-6 XML parsing C library - runtime li
ii  libglib2.0-0 2.22.3-1.0  The GLib library of C routines
ii  libhal-storage1  0.5.14-1Hardware Abstraction Layer - share
ii  libhal1  0.5.14-1Hardware Abstraction Layer - share
ii  libusb-0.1-4 2:0.1.12-13 userspace USB programming library
ii  lsb-base 3.2-23  Linux Standard Base 3.2 init scrip
ii  mount2.16.2-0Tools for mounting and manipulatin
ii  pciutils 1:3.1.4-4   Linux PCI Utilities
ii  udev 149-1   /dev/ and hotplug management daemo
ii  usbutils 0.86-2  Linux USB utilities

Versions of packages hal recommends:
ii  consolekit  0.4.1-2  framework for defining and trackin
ii  eject   2.1.5+deb1+cvs20081104-7 ejects CDs and operates CD-Changer
ii 

Bug#562068: additional note

[Willi Mann]

Additional note:

I discovered the problem when I looked at dmesg output. kern.log contains

Dec 22 12:09:44 x kernel: [90527.406754] hald-probe-inpu[27579]:
segfault at 800 ip b7743089 sp bfedb798 error 4 in
libc-2.10.2.so[b76d3000+141000]
Dec 22 12:09:44 x kernel: [90527.408479] hald-probe-inpu[27582]:
segfault at 800 ip b7753089 sp bffd3688 error 4 in
libc-2.10.2.so[b76e3000+141000]

for one try to restart hal. I should probbably use another core dump
format - mine does not include the pid...

WM



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

Bug#558010: same session?

[Willi Mann]

Hi!

Did you restart your session between the crashes? As this bug occurs in
some dbus it might be a protocol change - I saw a similar backtrace when
I upgraded gvfs - except in was in gtk filechooser using applications.

Do you know whether this bug already occured in 4.3.1?

WM



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

Bug#558010: upstream report

[Willi Mann]

Probably

https://bugs.kde.org/show_bug.cgi?id=208921

which was first reported for KDE 4.3.1.



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

Bug#554495: Please logout and login again

[Willi Mann]

Hi!

The simple solution is to logout and login again. The problem is caused
by a protocol change in gvfs.

See http://bugs.debian.org/548898

I leave it up to the maintainers to close this bug. Closing this bug
might cause more bug reports with the same problem. (And merging
probably doesn't make sense anymore, there are 8 other bug reports
already merged).

WM



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

Bug#554495: janitor, more info

[Willi Mann]

retitle 554495 Segfault when trying to saving messages or attachments
severity 554495 grave
found 554495 icedove/2.0.0.22-1
tag 554495 - patch
thanks

I can also reproduce this segfault, when trying to save attachments. The
actual segfault happens in a dbus library, for which not -dbg package is
available.

The first 10 items of the stack frame thus look like:


#0  0xb6c85bb6 in ?? () from /lib/libdbus-1.so.3
#1  0xb6c72e1d in ?? () from /lib/libdbus-1.so.3
#2  0xb6c72e89 in ?? () from /lib/libdbus-1.so.3
#3  0xb6c71d77 in ?? () from /lib/libdbus-1.so.3
#4  0xb6c72f60 in ?? () from /lib/libdbus-1.so.3
#5  0xb6c71d77 in ?? () from /lib/libdbus-1.so.3
#6  0xb6c7780b in dbus_message_iter_next () from /lib/libdbus-1.so.3
#7  0xacd5de92 in ?? () from
/usr/lib/gio/modules/libgioremote-volume-monitor.so
#8  0xacd64354 in ?? () from
/usr/lib/gio/modules/libgioremote-volume-monitor.so
#9  0xacd65b53 in ?? () from
/usr/lib/gio/modules/libgioremote-volume-monitor.so
#10 0xb767f526 in IA__g_object_newv (object_type=164742440,
n_parameters=0, parameters=0x0)
at
/build/buildd-glib2.0_2.22.2-2-i386-R8GTDn/glib2.0-2.22.2/gobject/gobject.c:1171


My guess is that the real cuprit is dbus or another package, but not
icedove, because with the current version, I already successfully saved
attachments a week ago.

WM



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

Bug#533978: fix: copyright problem needs to get fixed before upload

[Willi Mann]

tag 533978 + pending
thanks

Just for the record: I have a fix for this bug ready, however there
might be a licensing problem as upstream switched from GPL-2 (not or
later) to GPL-3.



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

Bug#467096: traverso: compiled with optimisations not supported on all i386 subarchitectures

[Willi Mann]

Hi!

You don't need to take any action on the bug as I have reopened it.
Hopefully, someone with enough experience with this kind of build
instructions can fix this. (Unfortunately, it's not a standard Makefile,
which i could fix)

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#467096: not really fixed

[Willi Mann]

reopen 467096 0.42.0-2
thanks

Hi!

According to the build log at

http://buildd.debian.org/fetch.cgi?pkg=traverso;ver=0.42.0-2;arch=i386;stamp=1207443881

the package is still compiled with too much optimisation.:

g++ -mmmx -m3dnow -march=i686 -msse -mfpmath=sse

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#467096: severity overstated?

[Willi Mann]

Hi!

Isn't the severity of this bug overstated? After all it has caused this
package to be removed from lenny despite the fact that it starts fine,
at least on my machine.

If nobody opposes, I'll downgrade this bug to important or normal.

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#467096: severity overstated?

[Willi Mann]

retitle 467096 traverso: compiled with optimisations not supported on
all i386 subarchitectures
thanks

 This version shows a bug which prevents traverso from runing at all
 on some systems. I do not know the criteria which are used to remove
 a package, but if lenny packages are supposed to run on duron 900,
 this package does not meet these requirements, exept you really think
 that starts fine, at least on my machine overrules does not start
 on duron900. As far as the reportbug requirements are concerned,
 this bug is severe.

Ok, I misread. I agree that this bug is RC, as the package is compiled
with too much optimisation: see

http://buildd.debian.org/fetch.cgi?pkg=traverso;ver=0.42.0-1;arch=i386;stamp=1197920375

-mmmx -m3dnow -march=i686 -msse -mfpmath=sse

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#462515: sqwebmail: installation fails

[Willi Mann]

 I don't know if it should supply it, but it doesn't.

Hi Racke, hi Lucas!

Why don't we just ship the directory /usr/lib/cgi-bin in the sqwebmail
package? Except for a lintian warning (empty directory), that should
work, AFAIK, as a directory can be owned by more than one package.

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#458636: sqwebmail-de: FTBFS: patching fails

[Willi Mann]

tag 458636 + pending
thanks

 During a rebuild of all packages in sid, your package failed to build on i386.
 
 Relevant part:

I know and a fixed package is available from
http://wserver.wm1.at/~willi/debian/various/pool/main/s/sqwebmail-de/

I'm waiting for a reply by Daniel Baumann, to tell me whether he will
sponsor the package (he sponsored the last upload).

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451818: intel graphics the reason?

[Willi Mann]

Hi!

I have this behaviour a little bit longer than 18 days, probably one or
two month. The most notable difference is that I'm on xf86-video-intel
git since some time.

Is everyone affected by this issue using the intel driver? Please report.

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451818: anyone willing to to a git bisect on the intel driver?

[Willi Mann]

Hi!

As it seems, the bug is caused by the intel driver. Anyone willing to
test the latest 2.1 version from snapshot.debian.net and then do a git
bisect?

For me, this is very unfunny, as the 2.1 versions crash very often on my
855GM.

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#451818: anyone willing to to a git bisect on the intel driver?

[Willi Mann]

 Can you try with Option AccelMethod XAA in xorg.conf (in the Device
 section)?

With this option, corruption gone.

Willi



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427516: Is this a 64-bit arch issue?

[Willi Mann]

Hi!

I tried to reproduce this problem on ia32, but failed. Has anybody
reproduced this bug on anything else but amd64?

Willi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]