Bug#894795: kde-full currently uninstallable

[Michael Karcher]

Package: kde-full
Version: 5:100
Severity: serious

Dear Maintainer,

kde-full from meta-kde 5:100 depends on kdepim 4:17.12.xxx, but
meta-kde provides the packages kdepim in Version 4:17.08.xxx.
Two untested fixes (choose one!) have been provided at
  https://salsa.debian.org/qt-kde-team/kde/meta-kde/merge_requests/4
and
  https://salsa.debian.org/qt-kde-team/kde/meta-kde/merge_requests/3

I ran reportbug on a system with kdepim 5:99 installed (as 5:100 is
uninstallable), so the dependency list below does contain a kdepim
version that is in conflict with kde-full 5:100.

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

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

Versions of packages kde-full depends on:
ii  kde-plasma-desktop   5:100
ii  kde-standard 5:100
ii  kdeadmin 4:17.08.3+5.100
ii  kdeedu   4:17.08.3+5.100
ii  kdegames 4:17.08.3+5.100
ii  kdegraphics  4:17.08.3+5.100
ii  kdemultimedia4:17.08.3+5.100
ii  kdenetwork   4:17.08.3+5.100
ii  kdepim   4:17.08.3+5.100
ii  kdeutils 4:17.08.3+5.100
ii  plasma-workspace-wallpapers  4:5.12.1-1

Versions of packages kde-full recommends:
pn  kdeaccessibility  
pn  kdesdk
pn  kdetoys   
pn  kdewebdev 

Versions of packages kde-full suggests:
pn  calligra  
ii  xorg  1:7.7+19

-- no debconf information

Bug#868868: emacs25: Please include patch to fix FTBFS on m68k

[Michael Karcher]

> On Jul 19 2017, John Paul Adrian Glaubitz 
> wrote:
>
>> "sizeof(struct Lisp_Symbol) is 22 bytes on m68k, but the code expects
>> the
>>  size of the object to be dividable by 8."
>
> No, it doesn't.  See union aligned_Lisp_Symbol.

Yes, it does, although this most likely is a bug.

While aligned_Lisp_Symbol is used in alloc.c, which is used for dynamic
allocations, and most likely works OK, it is not used for the array of
static symbols, lispsym. The declaration in globals.h (a generated file)
looks like this:

struct Lisp_Symbol alignas (GCALIGNMENT) lispsym[1101];

This does not generate an array of aligned elements, but an aligned array
of non-aligned elements. This is in line with the documented use case of
alignas to create aligned vectors of floats like "alignas(16) float
vector[4];" in which only the whole array gets aligned.

The issue can most likely be fixed by using the union (which currently is
only defined inside alloc.c) in globals.h. This means copying that
definition or putting that definition into a shared header file. globals.h
is generated by lib-src/make-docfile.c

Bug#849270: tin: forced authentication (-A) broken

[Michael Karcher]

Package: tin
Version: 1:2.4.0-1
Severity: normal

Dear Maintainer,

The patches you pulled from the unreleased version 2.4.1 are known to break
-A to force nntp authentication. A fix is available in
  http://lists.tin.org/pipermail/tin-dev/2016-December/42.html

Not being able to use -A breaks using the popular news server
news.eternal-september.org, as this server allows posting to a limit set
of groups even without authentication, so tin sees no reason to
authenticate. Most users of eternal-september.org need full access to
that server and not just to the limited set of groups exposed without
authentication, so forced authentication is needed here.

Regards,
  Michael Karcher

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

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

Versions of packages tin depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  libcanlock22b-8
ii  libicu57   57.1-5
ii  libncursesw5   6.0+20161126-1
ii  libpcre3   2:8.39-2
ii  libtinfo5  6.0+20161126-1
ii  libuu0 0.5.20-9

Versions of packages tin recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-1

Versions of packages tin suggests:
ii  gnupg   2.1.16-3
ii  ispell  3.4.00-5

-- debconf information:
  shared/news/server: news.eternal-september.org

Bug#828141: firebird2.5: Please add platform support for m68k

[Michael Karcher]

On 30.06.2016 02:29, John Paul Adrian Glaubitz wrote:

Hello!

Attaching an updated patch which includes an additional alignment fix for m68k
by Michael Karcher. He discovered that "sem_t" was incorrectly aligned to 16 
bits
which resulted in "create_db" crashing with [1]:

sh -x -c "lockfile -1 ../gen/firebird/bin/build-db.lock && 
../gen/firebird/bin/create_db empty.fdb; res=\$?; rm -f ../gen/firebird/bin/build-db.lock; exit 
\$res"
+ lockfile -1 ../gen/firebird/bin/build-db.lock
+ ../gen/firebird/bin/create_db empty.fdb
The futex facility returned an unexpected error code.Aborted
+ res=134
+ rm -f ../gen/firebird/bin/build-db.lock
+ exit 134
../gen/Makefile.refDatabases:66: recipe for target 'empty.fdb' failed

This updated patch fixes this issue. However, firebird2.5 continues to FTBFS on 
m68k [2]:

+ ../gen/firebird/bin/isql_static -i ../src/msgs/msg.sql msg.fdb
can't format message 17:0 -- message file 
/usr/lib/m68k-linux-gnu/firebird/2.5/firebird.msg not found
Dynamic SQL Error
-SQL error code = -104
-Unexpected end of command - line 1, column 18
can't format message 17:120 -- message file 
/usr/lib/m68k-linux-gnu/firebird/2.5/firebird.msg not found
can't format message 17:0 -- message file 
/usr/lib/m68k-linux-gnu/firebird/2.5/firebird.msg not found

Adrian
This turns out to be a problem of the build environment. Firebird 
creates its own btyacc (I did not yet verify whether Debian's btyacc has 
the same problem), which creates a broken parser inside qemu, but the 
same binary creates a correct parser when run in aranym, so the current 
build problem is very likely a bug in the qemu version used on that 
build host.
qemu on that host is built directly from the current upstream git 
revision, it is not an installed debian package.


Best regards,
  Michael Karcher

Bug#792204: Setting default CPU to ultrasparc for -m32 on sparc64 does not work

[Michael Karcher]

Hello,

the problem (ATOMIC_INT_LOCK_FREE == 1) applies for the 32-bit build of
libstdc++,
and is caused by gcc assuming a too old 32-bit sparc processor, as can
be seen by:

 (unstable-sparc64-sbuild)mkarcher@ravirin:~$ COLUMNS=140 dpkg -l gcc-4.9
 Desired=Unknown/Install/Remove/Purge/Hold
 |
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
 |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 ||/ Name  Version
ArchitectureDescription

+++-=-===-===-===
 ii  gcc-4.9   4.9.2-21+sparc64   
sparc64 GNU C compiler

(this is a custom build of the official debian gcc source with the
symbol verification
quieted by using fudged expected symbols lists)

 (unstable-sparc64-sbuild)mkarcher@ravirin:~$ g++-4.9 -std=c++11 -dM -E
-m32 -x c++ /dev/null | grep INT_LOCK  
 #define __GCC_ATOMIC_INT_LOCK_FREE 1
 (unstable-sparc64-sbuild)mkarcher@ravirin:~$ g++-4.9 -std=c++11 -dM -E
-m32 -mcpu=ultrasparc -x c++ /dev/null | grep INT_LOCK
 #define __GCC_ATOMIC_INT_LOCK_FREE 2

The changelog messages for gcc seem to indicate that the default CPU for
-m32 is
intended to be ultrasparc:

 gcc-4.9 (4.9.0-10) unstable; urgency=medium

   * Update to SVN 20140704 (r212295) from the gcc-4_9-branch.

   * Explicitly set cpu_32 to ultrasparc for sparc64 builds.
[...]
 gcc-4.9 (4.9.0-9) unstable; urgency=medium

   * Update to SVN 20140701 (r212192) from the gcc-4_9-branch.
   * Update libstdc++ symbols files for ARM.
   * Configure --with-cpu-32=ultrasparc on sparc64.

This seems to not have the intended effect of defaulting to require the
ultrasparc
architecture providing lock-free atomics.

Regards,
  Michael Karcher


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

Bug#768574: gcc-4.9: Miscompilation of boolean negation on SH4 using -O2

[Michael Karcher]

Package: gcc-4.9
Version: 4.9.1-16
Severity: important

The currently available version of gcc 4.9 for mips miscompiles boolean 
negation under certain circumstances.
The assembly contains the not instruction, which represents bitwise negation, 
which is not appropriate, as
both 0 and 1 get mapped to a non-zero bit-pattern, but the following check of 
the boolean tests it against 0.

See the attached example file. The assertion fails if compiled with -O2 but 
succeeds without optimization.
This is actually a heavily stripped-down example of a miscompilation of 
binutils, making linking of most C++
programs on SH4 fail. The misbehaviour of binutils is reported in
https://sourceware.org/bugzilla/show_bug.cgi?id=17553 , but this bug has been 
correctly rejected as it is
not caused by the binutils source code.

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sh4 (sh4a)

Kernel: Linux 3.2.44-00829-g14e6110 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-4.9 depends on:
ii  binutils2.24.90.20141104-1
ii  cpp-4.9 4.9.1-16
ii  gcc-4.9-base4.9.1-16
ii  libc6   2.19-11
ii  libcloog-isl4   0.18.2-1
ii  libgcc-4.9-dev  4.9.1-16
ii  libgmp102:6.0.0+dfsg-6
ii  libisl100.12.2-2
ii  libmpc3 1.0.2-1
ii  libmpfr43.1.2-1
ii  zlib1g  1:1.2.8.dfsg-2

Versions of packages gcc-4.9 recommends:
ii  libc6-dev  2.19-11

Versions of packages gcc-4.9 suggests:
pn  gcc-4.9-doc  none
pn  gcc-4.9-locales  none
pn  libasan1-dbg none
pn  libatomic1-dbg   none
pn  libcilkrts5-dbg  none
pn  libgcc1-dbg  none
pn  libgomp1-dbg none
pn  libitm1-dbg  none
pn  liblsan0-dbg none
pn  libquadmath-dbg  none
pn  libtsan0-dbg none
pn  libubsan0-dbgnone

-- no debconf information

*** /home/glaubitz/gcctest/gccfail.c
#include assert.h

int decision_result;
int truecount = 0;
int val;

void buggy(int flag)
{
  int condition;
  if(flag == 0)
condition = val != 0;
  else
condition = !decision_result;
  if (condition)
  {
 truecount++;
  }
}

int main(void)
{
  decision_result = 1;
  buggy(1);
  assert(truecount == 0);
}


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

Bug#768574: Acknowledgement (gcc-4.9: Miscompilation of boolean negation on SH4 using -O2)

[Michael Karcher]

Of course I meant to write The currently available version of gcc 4.9
for sh4... in the first paragraph of the bug description. I am sorry
for any confusion this might have caused.

Regards,
  Michael Karcher


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

Bug#682067: git can not clone fai config space

[Michael Karcher]

Hello everyone again,

I am sorry for my untested and wrong suggestion. I got feedback that it
doesn't work, which is due to my command is not unsetting GIT_WORK_TREE,
but setting it to an empty string instead. If the environment variable
GIT_WORK_TREE is needed (I presume it is), you need to unset it
temporarily in a subshell:
  ( unset GIT_WORK_TREE; git clone --branch ... )
I would be happy if someone tested this suggestion and can confirm that
it works.

Regards,
  Michael Karcher


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

Bug#682067: git can not clone fai config space

[Michael Karcher]

Hello all,

it seems like you trip around a kind of do-what-i-mean feature in git.
If you set GIT_WORK_TREE, git clone assumes you want a detached working
directory, and thus treats the command line argument as the directory
you want to be $GIT_DIR. So the patch to replace $FAI by $GIT_DIR in
fact does what is needed. On the other hand, breakage is observed by
that patch for other people, which seems to indicate that the behaviour
of git clone is not consistent over git versions.

The git version shipped in debian wheezy does the following if
GIT_WORK_TREE is set:
 - clones the repo into what you specify on the command line (not
into .git, no matter what the value of GIT_DIR is)
 - checks out the files into $GIT_WORK_TREE
 - marks the clone as non-bare repository with a non-standard working
tree at $GIT_WORK_TREE
As later git commands do honor $GIT_DIR, breakage occurs.

My suggestion is thus a different patch: unset GIT_WORK_TREE for the
checkout by running
  GIT_WORK_TREE= git clone --branch $gitbranch $giturl $FAI
you don't need to specify the work tree in the environment variable, as
you already pass the value on the command line.

Regards,
  Michael Karcher


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

Bug#707215: [kdevelop] Crashes when opening some C files

[Michael Karcher]

Package: kdevelop
Version: 4:4.3.1-3+b1
Followup-For: Bug #707215

The solution to this bug is indeed to rebuild kdevelop, as this
bug is caused by a bug in g++ 4.7.0 and 4.7.1 that caused ABI changes
in returning std::pairs (see http://gcc.gnu.org/gcc-4.7/changes.html).

The solution is to recompile kdevelop against any libstdc++ except for
4.7.0 or 4.7.1.

The problem in this case is related to

std::pairbool, std::size_t
std::__detail::_Prime_rehash_policy::_M_need_rehash
  (std::size_t, std::size_t, std::size_t, std::size_t);

declared in /usr/include/c++/4.7/bits/hashtable_policy.h

Until g++ 4.8, this function is defined as inline function in that file. 
This might seem to protect from ABI problems, but in fact, it does not. 
This is because the compiler decides the function is too complicated to be
inlined, so a compiled version of that function is emitted in every object
file calling that function.  The emitted function in a certain object is
always compatible to the ABI used in that object, but as soon as you link
multiple of these objects together, they share using only one function, and
all others get discarded (on static linking with ld) or ignored (on dynamic
linking).  As long as all objects linked together use the same ABI (either
the broken 4.7.0/4.7.1 ABI or the correct ABI), no problem arises.

As soon as you link code using the broken and the correct ABI, a
disaster happens.  While kdevelop itself is currently compiled against the
broken ABI, so it does not contain any copies of that function using the
correct ABI, it is supposed to work. That is until g++ 4.8 (and its
accompanying libstdc++). Because that function was emitted out-of-line
anyway, the libstdc++ developers decided it makes no sense to emit it
in every program and changed it from being inline into being a normal
non-inline function with its implementation in libstdc++. The result is
a libstdc++ containing one central implementation of that function, of
course using the correct ABI, as it is not compiled by g++ 4.7.0 or g++
4.7.1. Every program that loads libstdc++ (that is, every dynmaically
compiled C++ program) thus includes the correct function. If the first
shared object using that function gets loaded after libstdc++, the central
version with the correct ABI is used, and the local version with the
broken ABI is ignored, breaking that shared object.

This is why libstdc++6 created from g++ 4.8 breaks kdevelop.

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

Kernel: Linux 3.10.0-rc4+ (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages kdevelop depends on:
ii  kde-runtime4:4.8.4-2
ii  kdevelop-data  4:4.3.1-3
ii  kdevplatform5-libs 1.3.1-2
ii  libc6  2.17-3
ii  libgcc11:4.8.0-7
ii  libkasten1controllers1 4:4.8.4+dfsg-1
ii  libkasten1core14:4.8.4+dfsg-1
ii  libkasten1okteta1controllers1  4:4.8.4+dfsg-1
ii  libkasten1okteta1core1 4:4.8.4+dfsg-1
ii  libkasten1okteta1gui1  4:4.8.4+dfsg-1
ii  libkcmutils4   4:4.8.4-4
ii  libkdecore54:4.8.4-4
ii  libkdeui5  4:4.8.4-4
ii  libkio54:4.8.4-4
ii  libkparts4 4:4.8.4-4
ii  libktexteditor44:4.8.4-4
ii  libplasma3 4:4.8.4-4
ii  libprocessui4a 4:4.8.4-6
ii  libqt4-dbus4:4.8.4+dfsg-4
ii  libqt4-help4:4.8.4+dfsg-4
ii  libqt4-network 4:4.8.4+dfsg-4
ii  libqt4-script  4:4.8.4+dfsg-4
ii  libqtcore4 4:4.8.4+dfsg-4
ii  libqtgui4  4:4.8.4+dfsg-4
ii  libqtwebkit4   2.2.1-5
ii  libstdc++6 4.8.0-7
ii  libsublime51.3.1-2
ii  libthreadweaver4   4:4.8.4-4

Versions of packages kdevelop recommends:
ii  g++   4:4.7.2-1
ii  gcc   4:4.7.2-1
ii  gdb   7.4.1+dfsg-0.1
ii  make  3.81-8.2

Versions of packages kdevelop suggests:
ii  cmake  2.8.11-2
pn  kapptemplate   none
pn  kdevelop-l10n  none

-- no debconf information


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

Bug#703281: rygel security issue

[Michael Karcher]

Package: rygel
Version: 0.14.3-2
Followup-For: Bug #703281

This behaviour is caused by the global (system wide) configuration file
/etc/rygel.conf containing upnp-enabled=true. That file is used as
template for the local (user specific) configuration file, which is written
when you exit rygel-preferences.

On the other hand, to avoid messing with autostart settings of a user that
did not enable UPnP his/herself, rygel-preferences treats the parameter
upnp-enabled as false, if it was loaded from the global configuration
file.

This behaviour has been introduced in commit
https://git.gnome.org/browse/rygel/commit/src/ui?id=4ab1d1f905f38b17cf162c6b34b763a40a292b4e

A short-term fix would be to ship with upnp-enabled=false in the global
configuration file. Which might even actually be what Debian wants. I did 
not track down whether the global true setting already makes the UPnP
interface available while rygel is running.

Regards,
  Michael Karcher

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

Kernel: Linux 3.7.0+ (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages rygel depends on:
ii  libc62.16-0experimental1
ii  libgee2  0.6.4-2
ii  libglib2.0-0 2.34.3-1
ii  libgssdp-1.0-3   0.12.1-2
ii  libgstreamer-plugins-base0.10-0  0.10.36-1.1
ii  libgstreamer0.10-0   0.10.36-1.1
ii  libgupnp-1.0-4   0.18.3-1
ii  libgupnp-av-1.0-20.10.2-1
ii  libgupnp-dlna-1.0-2  0.6.6-1
ii  libsoup2.4-1 2.40.1-1
ii  libsqlite3-0 3.7.13-1
ii  libunistring00.9.3-5
ii  libuuid1 2.20.1-5.3
ii  libxml2  2.8.0+dfsg1-7+nmu1

Versions of packages rygel recommends:
ii  gstreamer0.10-ffmpeg0.10.13-5
ii  gstreamer0.10-plugins-base  0.10.36-1.1
ii  gstreamer0.10-plugins-ugly  0.10.19-2+b2

Versions of packages rygel suggests:
pn  rygel-mediatheknone
pn  rygel-playbin  none
ii  rygel-preferences  0.14.3-2
pn  rygel-tracker  none
ii  tumbler0.1.25-1+b1

-- no debconf information


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

Bug#704769: FTBFS on s390x sid buildds.

[Michael Karcher]

Package: libarchive
Severity: normal


The test failures are caused by a bug in libarchive on big-endian 64 bit
architectures, as already suspected. There indeed is an upstream fix for
it, it is in commit da058d4b1a240a3381f37f99ef9edd982e34cabc fixing the
data type of some variable passed to an ioctl call.

The failure is not related to ext3 vs. ext4, but most likely indicates
that the buildd does not use tmpfs on /tmp. The bug does not manifest
on tmpfs file systems, and the testsuite is running in a subdir of
/tmp, which can be overriden using TMPDIR. Running it with TMPDIR
set to a ext3-backed directory makes it fail on the porterbox, too.

The upstream diff from the mentioned commit is attached.

Regards,
  Michael Karcher

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

Kernel: Linux 3.2.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
commit da058d4b1a240a3381f37f99ef9edd982e34cabc
Author: Andreas Schwab sch...@linux-m68k.org
Date:   Wed Aug 29 15:41:51 2012 +0200

Fix more uses of EXT2_IOC_[GS]ETFLAGS

diff --git a/libarchive/archive_read_disk_posix.c b/libarchive/archive_read_disk_posix.c
index 698600e..652deb9 100644
--- a/libarchive/archive_read_disk_posix.c
+++ b/libarchive/archive_read_disk_posix.c
@@ -984,7 +984,7 @@ next_entry(struct archive_read_disk *a, struct tree *t,
 #elif defined(EXT2_IOC_GETFLAGS)  defined(EXT2_NODUMP_FL) \
   defined(HAVE_WORKING_EXT2_IOC_GETFLAGS)
 		if (S_ISREG(st-st_mode) || S_ISDIR(st-st_mode)) {
-			unsigned long stflags;
+			int stflags;
 
 			t-entry_fd = open_on_current_dir(t,
 			tree_current_access_path(t), O_RDONLY | O_NONBLOCK);
diff --git a/libarchive/archive_write_disk_posix.c b/libarchive/archive_write_disk_posix.c
index d79b0f6..6b8bfde 100644
--- a/libarchive/archive_write_disk_posix.c
+++ b/libarchive/archive_write_disk_posix.c
@@ -2403,8 +2403,8 @@ set_fflags_platform(struct archive_write_disk *a, int fd, const char *name,
 {
 	int		 ret;
 	int		 myfd = fd;
-	unsigned long newflags, oldflags;
-	unsigned long sf_mask = 0;
+	int newflags, oldflags;
+	int sf_mask = 0;
 
 	if (set == 0   clear == 0)
 		return (ARCHIVE_OK);

Bug#624507: #624507 - Started looping and continuously rewriting metadata file - Debian Bug report logs

[Michael Karcher]

Indeed that looping behaviour is not bound to occur only on remote file
systems, but it is caused by the current version of the database file
(like home) not referring to the redo log (like home-01234567.log)
that is currently opened by the gvfsd (because it was referred to by the
database at the time gvfsd opened the database).

The usual reason for this mismatch is that the database has been
replaced by a different version referring a different redo log file, but
it could be due to data corruption, too. As long as the data base (and
the redo log) is only used on a single system, the kernel (mostly?)
ensures that once a redo log has been rotated into the data base, the
this redo log is rotated-Bit is also seen by all other processes using
the same redo log. This is why the bug usually does not appear in the
single-system setup.
There at least two different possible scenarios, how the mismatch could
arise on a local file system, too:
 a) The local file system is exported, and the log has been rotated by a
remote machine.
 b) The gvfs-metadata database directory has been restored from a backup
while gvfsd-metadata was running.

The temporary fix of disabling the metadata recording on remote file
systems would help in scenario a, but not in scenario b.

Regards,
  Michael Karcher


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

Bug#634261: [sparc] iceweasel: Bus Error in setbuf()

[Michael Karcher]

A summary of the current situation:

There are historic programs and libraries relying on the old FILE
structure. These programs and libraries assume that any 4-byte aligned
FILE structure is acceptable, because that was the case with libio 2.0

Most programs and libraries are compiled with libio 2.1. At least on
sparc, this means that FILE objects now need to be aligned on an 8-byte
boundary. The compiler assumes this alignment when generating code using
libio 2.1 (or newer) headers.

The alignment difference is the cause that even though glibc maintainers
took a lot of effort to make the old and the new structure compatible,
there can be unexpected problems on sparc, because it seems like the
alignment issue was not considered at that time.

There is no silver bullet - either we have an 8-byte alignment
requirement, which keeps compatibility with all libio 2.1 code, or we
relax the requirement to 4-byte alignment (by splitting the 64-bit
offset field and implementing the 64-bit-arithmetic by hand), which will
re-enable full compatibility with libio 2.0 code. Especially as libio
2.0 and libio 2.1 libraries can be dynamically mixed, and all code
expects that FILE* pointers of the old and new variant are
interchangable for the narrow-character interface, there is some mess
outside of glibc already that can never be fixed.

A way to minimize the symptoms of this bug is to notice that most, if
not all, FILE structures are allocated inside libc. As long as libc code
controls the address of FILE objects, it can ensure 8-byte alignment,
even for the legacy structures. So my recommendation is:

1. keep not forcing old FILE* to be 8-byte-aligned

Forcing it would make the legacy function (versioned GLIBC_2.0) unable
to cope with (unaligned) objects they currently can cope with


2. do force 8-byte-alignment on the legacy stdin/stdout/stderr

This will make the legacy standard streams compatible with current code


3. do force 8-byte aligment on functions generating FILE structures
(like fopen), even in the legacy interface.

This will make all stream objects allocated in libc functions (which
probably will be all stream objects you encounter) compatible with
current code.


I am completely aware (as pointed out above) that this is not a perfect
fix, but it should be a good enough fix that no observable problems
occur, even if you mix libio 2.0 and libio 2.1 code.

And finally:
4. implement a lintian check that shared objects (programs and
libraries) importing any GLIBC_2.1 or later versioned symbol also
contain an *unversioned* export of _IO_stdin_used on those architectures
where libio 2.0-compatibility is enabled (for example i386, but not
amd64).

In my oppinion, this bug is definitely not release critical, because the
only thing that is broken is a compatiblity layer for programs more than
10 years old. This would count as a particular option (or menu item)
of libc6, furthermore not affecting the core functionality of the
package. So the priority should be normal or minor.

A build process that mangles the export of _IO_stdin_used is (as defined
by the libc ABI, even if not explicitly written down) broken. The bug in
this case was caused by such a kind of broken build process in the
Mozilla applications that already has been fixed. We are still waiting
for a real manifestation of the original bug, which should occur with
libio 2.0 programs only.

Regards,
  Michael Karcher


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

Bug#695614: CVE-2012-6303: buffer overflows

[Michael Karcher]

The attached patch fixes the buffer overrun for the fixed-size header
buffer.
--- snack-2.2.10-dfsg1/generic/jkSoundFile.c	2005-12-14 12:29:38.0 +0100
+++ snack-2.2.10-dfsg1+karcher/generic/jkSoundFile.c	2013-01-02 00:29:56.836287036 +0100
@@ -1796,7 +1796,14 @@
 GetHeaderBytes(Sound *s, Tcl_Interp *interp, Tcl_Channel ch, char *buf, 
 	   int len)
 {
-  int rlen = Tcl_Read(ch, buf[s-firstNRead], len - s-firstNRead);
+  int rlen;
+
+  if (len  max(CHANNEL_HEADER_BUFFER, HEADBUF)){
+Tcl_AppendResult(interp, Excessive header size, NULL);
+return TCL_ERROR;
+  }
+
+  rlen = Tcl_Read(ch, buf[s-firstNRead], len - s-firstNRead);
 
   if (rlen  len - s-firstNRead){
 Tcl_AppendResult(interp, Failed reading header bytes, NULL);

Bug#634261: [sparc] iceweasel: Bus Error in setbuf()

[Michael Karcher]

Am Sonntag, den 23.12.2012, 00:13 +0100 schrieb John Paul Adrian
Glaubitz:
  I don't completely follow, so I'll just ask: do you mean that this is
  a case of ABI misuse, with poor error reporting?
One could phrase it this way.

 As far I understand the problem, the Mozilla developers provide a
 version script to the linker to control which symbols get
 exported. This helps speeding up the load process of the binary and
 reduces the memory footprint.
This is correct.

 What the Mozilla developers didn't seem to put into account is that if
 you prevent the symbol _IO_stdin_used from being exported from your
 binary, parts of the ABI of the standard C library will change and it
 will behave like an older version which causes the unaligned access
 which results in a CPU trap.
And this is mostly correct. libc puts lots of effort in providing a
stable ABI. A big change in libc was the introduction of libio 2.1. It
introduced support for wide-character streams and 64 bit offsets. These
changes required an incompatible change to the FILE structure.

Because of this, the FILE APIs exist in two variants in glibc[1], if
backward compatibility is enabled. The new variant is tagged with the
version GLIBC_2.1, while the old one is tagged GLIBC_2.0. For the three
standard streams, there are two differently *named*, not just
differently *versioned* objects, namely _IO_stdin_ for the old version
and _IO_2_1_stdin_ for the new version, while the pointer stdin itself
is not version dependent. This might be to make sure that stdin itself
has the same value regardless of the version of libc that is imported.

If a program compiled against the glibc 2.1 (or newer) development
files, it will automatically refer to the new functions (i.e. link to
the GLIBC_2.1 version of _IO_file_setbuf and so on), while programs and
libraries compiled with old glibc 2.0 development files will refer to
the GLIBC_2.0 version of these functions.

The tricky part are the std* pointers:

If a source file is compiled with new development headers and refers to
stdin, stdout or stderr, some magic makes the compiler or linker emit a
definition of the symbol _IO_stdin_used in that module. glibc itself
defines it as a *weak* external symbol. The consequence is that if the
symbol is not defined anywhere, it just resolves to address 0, but if it
is defined in one or more modules, it resolves to a valid address in one
of these modules. The resolution of external global variables in ELF
systems is internally performed by a GOT lookup (which is the strange
code for _IO_stdin_used observed on disassembling) at runtime.

The logic in glibc is that if the new libio functions are used with
stdin, there will be a reference to _IO_stdin_used. But if there are no
references to _IO_stdin_used, the compatibility layer will kick in, and
make the stdin/stdout/stderr pointers by pointers to the compatibility
objects.

As it happens, the compatibility objects do not contain any 64 bit
field, and require a 4-byte-alignent on sparc, while the modern objects
(which are in fact the compatibility objects with some extra fields
appended) have a 64 bit field containing the current file offset. This
makes gcc on sparc require an 8-byte-alignment. gcc compiles functions
that work on the new FILE structure with the internal assumption that
these objects are aligned as they should, so it expects
8-byte-alignment. The old functions on the other hand work fine with the
new structures, stricter aligned, unless the code tries to access the
vtable pointer, which is at different location in the old and new
object, and most likely the cause to have both versions.

It might have been the intention of the libio developers that (unless
vtable accesses happen) the old objects can be processed by the new
functions, and in that case, glibc is buggy, as it relies on undefined
behaviour. Aussuming that intention, it expects that a pointer to the
short file structure can be used as a pointer to the long file
structure, which is not something you are granted by the C standard.

  Can you describe what iceweasel was doing wrong?  Is this documented
  so future coders know not to make the same mistake?  Is the version in
  squeeze affected?  How about the version in wheezy?
 It seems to have been fixed in Firefox 10 which is part of Wheezy:

There seems to be no official documentation on it, but hiding the
_IO_stdin_used symbol (it still is there, but not visible for dynamic
loading) violates internal glibc assumptions and breaks on sparc.

Regards,
  Michael Karcher

[1] This is why Bernhard R. Link observed the two different alignof
values. You choose between the two variants of FILE/_IO_FILE by defining
or not defining _IO_USE_OLD_IO_FILE. In oldstdfile.c, the symbol is
defined, while in genops.c, it is not defined.


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

Bug#660411: libxi6: Memory corruption when used with recent X servers

[Michael Karcher]

Package: libxi6
Version: 2:1.3-6
Severity: important
Tags: upstream patch

libXi can cause heap corruption if it receices unknown device classes
in input devices, as it does not allocate any space to unknown classes,
yet it stores type and ID information of that class. If the unknown classes
are at the end of the list, 8 bytes following the allocated class info
block are corrupted.

This behaviour is observable with current X servers in experimental. As
heap corruption is a security problem (malign X servers could try to exploit
client code using Xinput2), fixing this bug might be eligible for a stable
update.

Commit
http://cgit.freedesktop.org/xorg/lib/libXi/commit/?id=635c2c029b1e73311c3f650bcaf7eeb9e782134b
fixes the problem and applies (with offset and fuzz, though).

Regards,
  Michael Karcher

-- System Information:
Debian Release: 6.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 2.6.32-5-486
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libxi6 depends on:
ii  libc6 2.11.3-2   Embedded GNU C Library: Shared lib
ii  libx11-6  2:1.3.3-4  X11 client-side library
ii  libxext6  2:1.1.2-1  X11 miscellaneous extension librar

libxi6 recommends no packages.

libxi6 suggests no packages.

-- no debconf information



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

Bug#660413: ia32-libs: contained libxi corrupts memory with recent X servers

[Michael Karcher]

Package: ia32-libs
Version: 20120102
Severity: important

ia32-libs contains libxi6 2:1.3-6, which is affected by #660411. Recent
versions of Wine use XInput 2 if available, which causes memory corruption
and possible crashes. As mentioned in #660411 this affects security in
case of a malign X server.

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

Kernel: Linux 3.2.0-rc5+ (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ia32-libs depends on:
ii  dpkg   1.16.1.2
ii  lib32asound2   1.0.24.1-4
ii  lib32bz2-1.0   1.0.6-1
ii  lib32gcc1  1:4.6.2-12
ii  lib32ncurses5  5.9-4
ii  lib32stdc++6   4.6.2-12
ii  lib32v4l-0 0.8.5-7
ii  lib32z11:1.2.3.4.dfsg-3
ii  libc6-i386 2.13-26

ia32-libs recommends no packages.

Versions of packages ia32-libs suggests:
ii  ia32-libs-gtk  20120102

-- no debconf information





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

Bug#637931: results obtained with the perl debugger

[Michael Karcher]

Some hints to the reported bug: I ran the perl debugger on Adrian's
machine investigating the issue a bit, but did not do a full
investigation. This is what I came up with:

The download step crashes (i.e. the exec dies) at the point the
downloading message is printed to to stdout (Utility.pm:206), because
$stdout is undef at that point. It has been set to undef by the
preparation of the download restoring $stdout from $saved_stdout, the
latter being undefined. A breakpoint to open_log which should initialize
$saved_stdout did not trigger, so open_log was not called.

I did not investigate further why there was no call to open_log.

Regards,
  Michael Karcher




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

Bug#600589: hostapd + bridge for post 2.6.32

[Michael Karcher]

Hello,

your upgraded kernel is the cause of the problem: As bridging WLAN STA
interfaces (not access point) does not work, the WLAN interface can only
be part of a bridge when it already is in master mode from 2.6.33
onwards. So this does not apply to the default squeeze kernel.

If you first start hostapd and then add to the bridge, the addition to
the bridge works, but as soon as you add the WLAN to the bridge, the
EAPOL replies are received on the bridge interface instead of the WLAN
interface. If the bridge was not set up before you start the bridge,
hostapd fails to monitor the bridge interface for EAPOL replies, and
thus won't receive them, even if the bridge is created later on.

There are two possible solutions:
1) create bridge first, then start hostapd, then add the interfaces to
the bridge (difficult to implement as creation + adding interfaces is
done in the same ifupdown script in debian)
2) Upgrade to hostapd v0.7.1 or later. These versions of hostapd deal
better with newer kernels in that they can add the interface to the
bridge by themselves. hostapd v0.7.3 is available in experimental.

The following interfaces works for me with hostapd from experimental:

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

auto lo eth0 wlan0 br0
iface lo inet loopback

iface eth0 inet manual
iface wlan0 inet manual

iface br0 inet dhcp
bridge_fd 0
# hostapd will add wlan0 to the bridge... don't list it here
bridge_ports eth0
bridge_hw 00:0f:b5:80:d3:25
hostapd /etc/hostapd/hostapd.conf

And in /etc/hostapd/hostapd.conf I have

interface=wlan0
bridge=br0

Regards,
  Michael Karcher




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

Bug#553412: imapsync: Fixable by uncommenting 'use Term::ReadKey;'

[Michael Karcher]

Am Montag, den 11.01.2010, 17:36 +0100 schrieb Gilles LAMIRAL:
  Package: imapsync
  Version: 1.286+dfsg-3
 ^
  Severity: normal
  
  The problem is easily fixed by removing the comment sign before
  use Term::ReadKey;. I don't see why this line was commented out.
 Because there is a require when needed.
This statement is untrue. In
http://www.linux-france.org/prj/imapsync/dist/imapsync-1.286.tgz, there
is a require when needed, but this one is commented out, too. This bug
is fixed in a later upstream version, though.

 Because I know only one user needing it.
 The module is listed in the INSTALL file.
 I won't uncomment this line since there is no
 problem when packagers read and apply the INSTALL file.
I don't see at all how this rant against packagers is related to the
obvious bug in Version 1.286.

 If the automatic tools are not smart enough, get them smart
 by changing the 'grep use' with 'grep use or require'.
Did you even bother to check whether debian uses automatic tools to find
the dependency?

And now to something productive: Debian should just upgrade to a newer
upstream version to fix the bug.

Regards,
  Michael Karcher




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

Bug#553412: imapsync: Fixable by uncommenting 'use Term::ReadKey;'

[Michael Karcher]

Am Dienstag, den 09.03.2010, 01:42 +0100 schrieb Gilles LAMIRAL:
If the automatic tools are not smart enough, get them smart
by changing the 'grep use' with 'grep use or require'.
   Did you even bother to check whether debian uses automatic tools to find
   the dependency?
 Debian doesn't use automatic tools to find the dependency?
 That's worst than I though.
Now it seems you are contradicting yourself. Packagers not reading
INSTALL files are bad, but packagers finding the dependencies by hand
are bad too? In fact, I don't know whether there is an automated tool
that generates the dependencies of perl packages like there is for
dynamically linked ELF binaries, but definitely in the case of your
package, the debian control file explicitly states:

Depends: perl, libdigest-hmac-perl, libterm-readkey-perl,
libio-socket-ssl-perl, libdate-manip-perl, libmail-imapclient-perl (=
3.20-2), ${misc:Depends}

misc:Depends gets replaced by the debian packaging system by
dependencies introduced on building the package. The dependencies happen
to match exactly what you specifiy in your INSTALL file (except
Digest::MD5 is missing, as this is now packaged with base perl).

   And now to something productive: Debian should just upgrade to a newer
   upstream version to fix the bug.
 It's not productive since Debian stable never upgrade to a newer upstream
 version to fix a bug, unless for a security bug.
Did you consider checking which releases of debian 1.286 is in?
Hint: stable contains 1.252
See: http://packages.debian.org/search?keywords=imapsync

 We can conclude that debian stable is unstable
 by all the no-security then no-fixed bugs.
This has upsides and downsides. Consider the admin that made an ugly
workaround for a bug in stable, that would break if the bug were fixed
(which is a common property of bugs needing an ugly workaround). If an
update withing stable suddenly fixes the bug, the workaround breaks. The
idea of stable is to get security updates without having to worry about
this kind of issues on update.

And yes: I have been annoyed by unfixed bugs in stable, too, even up to
the point of recompiling patched packages.

Regards,
  Michael Karcher




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

Bug#571640: debhelper: qmake build system can't be set to use qmake-qt3 or qmake-qt4

[Michael Karcher]

Am Dienstag, den 02.03.2010, 07:44 +1000 schrieb Kel Modderman:
  The qmake build system in debhelper calls qmake, which, dependent on
  installed packages, is either Qt 3 or the Qt 4 version. If both Qt versions
  are installed, qmake defaults to qmake-qt3 (priority 45) over qmake-qt4
  (priority 40), making the automatic build system unable to build Qt 4
  packages.
 In the future, these build systems may be able to handle their own specific
 options. This build system could accept a --qmake option which sets the
 qmake binary to be called.
That sounds like a good idea.

  An option to choose either qmake-qt3 or qmake-qt4, or even hard
  wiring qmake-qt4 as the automatic build system is mainly used for new
  packages that mainly use qt4 would be nice, IMHO.
 Hardcoding anything would be crap.
Which also applies to qmake (as it is now) as well. qmake-qt4 is at
least consistent on all Debian Systems, without needing a
Build-Conflicts on Qt3's qmake.

Thanks for your response to the bug report,
  Michael Karcher




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

Bug#571640: debhelper: qmake build system can't be set to use qmake-qt3 or qmake-qt4

[Michael Karcher]

Package: debhelper
Version: 7.4.13
Severity: normal

The qmake build system in debhelper calls qmake, which, dependent on
installed packages, is either Qt 3 or the Qt 4 version. If both Qt versions
are installed, qmake defaults to qmake-qt3 (priority 45) over qmake-qt4
(priority 40), making the automatic build system unable to build Qt 4
packages.

An option to choose either qmake-qt3 or qmake-qt4, or even hard
wiring qmake-qt4 as the automatic build system is mainly used for new
packages that mainly use qt4 would be nice, IMHO.

Regards,
  Michael Karcher

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

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

Versions of packages debhelper depends on:
ii  binutils  2.20-6 The GNU assembler, linker and bina
ii  dpkg-dev  1.15.5.6   Debian package development tools
ii  file  5.04-1 Determines file type using magic
ii  html2text 1.3.2a-14  advanced HTML to text converter
ii  man-db2.5.6-5on-line manual pager
ii  perl  5.10.1-11  Larry Wall's Practical Extraction 
ii  perl-base 5.10.1-11  minimal Perl system
ii  po-debconf1.0.16 tool for managing templates file t

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make   0.51   tool that converts source archives

-- no debconf information



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

Bug#551783: libgpgme11: FTBFS with concurrency enabled (-jN)

[Michael Karcher]

Package: libgpgme11
Version: 1.2.0-1
Severity: normal


while debian policy does not mandate that debian/rules is concurrency-safe,
it is surely a nice thing. Regretfully the debian/rules contains a flaw that
makes it unsafe:

 begin quote
build: configure-stamp build-stamp
build-stamp:
 end quote

This tells make that for build, it can create configure-stamp and
build-stamp in parallel.  This fails as invoking make before configure
created a Makefile can not work.  It should read

 begin replacement
build: build-stamp
build-stamp: configure-stamp
 end replacement

This tells make that to create build-stamp for build, but before creating
build-stamp can even be started, configure-stamp has to be finished.

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

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

Versions of packages libgpgme11 depends on:
ii  gnupg 1.4.10-2   GNU privacy guard - a free PGP rep
ii  libc6 2.9-25 GNU C Library: Shared libraries
ii  libgpg-error0 1.6-1  library for common error values an
ii  libpth20  2.0.7-14   The GNU Portable Threads

libgpgme11 recommends no packages.

Versions of packages libgpgme11 suggests:
ii  gpgsm 2.0.13-1   GNU privacy guard - S/MIME version

-- no debconf information



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

Bug#550958: gparted: The error message for NTFS partitions if ntfsprogs is not installed is too generic

[Michael Karcher]

Package: gparted
Version: 0.4.6-2
Severity: wishlist

When I run gparted on a system without ntfsprogs installed, I get the
warning sign on NTFS partitions because gparted can't work on NTFS
partitions without ntfsprogs. That's all fair, but the explanation for the
warning sign is

Unable to read the contents of this file system! Because of this some
operations may be unavailable.

while it would be much more informative if it read

ntfsresize --info failed for this file system. Check that ntfsprogs is
installed

or something like that. I know that there is a Suggests: ntfsprogs on
gparted in Debian, but I still think this error message should be improved.

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

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

Versions of packages gparted depends on:
ii  hal   0.5.13-3   Hardware Abstraction Layer
ii  libc6 2.9-25 GNU C Library: Shared libraries
ii  libgcc1   1:4.4.1-1  GCC support library
ii  libglib2.0-0  2.22.0-1   The GLib library of C routines
ii  libglibmm-2.4-1c2 2.20.1-1   C++ wrapper for the GLib toolkit (
ii  libgtk2.0-0   2.16.6-1   The GTK+ graphical user interface 
ii  libgtkmm-2.4-1c2a 1:2.16.0-2 C++ wrappers for GTK+ 2.4 (shared 
ii  libpangomm-1.4-1  2.24.0-3   C++ Wrapper for pango (shared libr
ii  libparted1.8-12   1.8.8.git.2009.07.19-5 The GNU Parted disk partitioning s
ii  libsigc++-2.0-0c2 2.0.18-2   type-safe Signal Framework for C++
ii  libstdc++64.4.1-1The GNU Standard C++ Library v3

Versions of packages gparted recommends:
ii  gksu  2.0.2-2+b1 graphical frontend to su

Versions of packages gparted suggests:
pn  dmraid   none  (no description available)
ii  dmsetup  2:1.02.37-1 The Linux Kernel Device Mapper use
ii  dosfstools   3.0.5-1 utilities for making and checking 
pn  jfsutils none  (no description available)
ii  kpartx   0.4.8-15create device mappings for partiti
ii  ntfsprogs2.0.0-1 tools for doing neat things in NTF
pn  reiser4progs none  (no description available)
pn  reiserfsprogsnone  (no description available)
pn  xfsprogs none  (no description available)
ii  yelp 2.26.0-3Help browser for GNOME

-- no debconf information




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

Bug#548124: xmakemol-gl is compiled without GL support

[Michael Karcher]

Package: xmakemol-gl
Version: 5.16-3
Severity: normal

as the dependencies of the xmakemol-gl package already indicate, xmakemol
is not linked against the OpenGL libraries and the Open GL setup dialog
is missing. It looks like the non-OpenGL version that should be distributed
in xmakemol somehow sneaked into the package that should be OpenGL enabled.

Regards,
  Michael Karcher

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

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

Versions of packages xmakemol-gl depends on:
ii  lesstif21:0.95.0-2.3 OSF/Motif 2.1 implementation relea
ii  libc6   2.9-25   GNU C Library: Shared libraries
ii  libx11-62:1.2.2-1X11 client-side library
ii  libxext62:1.0.4-1X11 miscellaneous extension librar
ii  libxi6  2:1.2.1-2X11 Input extension library
ii  libxpm4 1:3.5.7-2X11 pixmap library
ii  libxt6  1:1.0.6-1X11 toolkit intrinsics library

xmakemol-gl recommends no packages.

Versions of packages xmakemol-gl suggests:
pn  gifsicle none  (no description available)
ii  imagemagick  7:6.5.5.3-1 image manipulation programs
pn  openbabelnone  (no description available)
ii  transfig 1:3.2.5.a-2 Utilities for converting XFig figu

-- no debconf information




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

Bug#483975: xosview: Interrupt indicator shows a dead place before last IRQ

[Michael Karcher]

Package: xosview
Version: 1.8.3+debian-6
Severity: minor
Tags: patch

xosview parses /proc/interrupts and stops parsing a little bit too late,
so the last number from /proc/interrupts gets processed twice. Please
apply the attached patch.

Regards,
  Michael Karcher

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

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

Versions of packages xosview depends on:
ii  libc6 2.7-10 GNU C Library: Shared libraries
ii  libgcc1   1:4.3.0-3  GCC support library
ii  libstdc++64.3.0-3The GNU Standard C++ Library v3
ii  libx11-6  2:1.0.3-7  X11 client-side library

xosview recommends no packages.

-- no debconf information


20_fix_reading_interrupts.dpatch
Description: application/shellscript

Bug#483815: xosview crashes if interrupt numbers exceed 1024

[Michael Karcher]

Package: xosview
Version: 1.8.3+debian-6
Severity: normal
Tags: patch

xosview has a fixed-size array mapping numbers from /proc/interrupts
to interrupt indicator positions. The size of this map is 1024. On some
x86-64 system (and probably modern i386 systems too) with PCI express,
the interrupt numbers the kernel uses for the Message Signalled Interrupt
might well exceed 1024.

The appended patch makes xosview use a dynamic map instead of an static
array.

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

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

Versions of packages xosview depends on:
ii  libc6 2.7-10 GNU C Library: Shared libraries
ii  libgcc1   1:4.3.0-3  GCC support library
ii  libstdc++64.3.0-3The GNU Standard C++ Library v3
ii  libx11-6  2:1.0.3-7  X11 client-side library

xosview recommends no packages.

-- no debconf information

#! /bin/sh /usr/share/dpatch/dpatch-run
## handle_high_irq_numbers.dpatch by  [EMAIL PROTECTED]
##
## Uses a dynamic map instead of a fixed-size array for interrupt mapping,
## as some x86-64 systems have the MSI interrupts way beyond 1024.

@DPATCH@
diff -urNad xosview-1.8.3+debian~/linux/intmeter.cc 
xosview-1.8.3+debian/linux/intmeter.cc
--- xosview-1.8.3+debian~/linux/intmeter.cc 2008-05-31 12:25:04.656454148 
+0200
+++ xosview-1.8.3+debian/linux/intmeter.cc  2008-05-31 12:27:10.861106922 
+0200
@@ -11,13 +11,14 @@
 #include cpumeter.h
 #include fstream
 #include sstream
+#include map
 #include stdlib.h
 
 
 static const char *INTFILE = /proc/interrupts;
 static const char *VERSIONFILE = /proc/version;
 
-static int realintnum[1024];
+std::mapint,int realintnum;
 
 IntMeter::IntMeter( XOSView *parent, int cpu)
   : BitMeter( parent, INTS, , 1,
@@ -114,10 +115,11 @@
setNumBits(n+1);
std::ostringstream os;
 
-   os  INTs (0-16 ;
-   for (int i=16; i1024; i++) {
-   if (realintnum[i])
-  os  ,   (i) ;
+   os  INTs (0-15 ;
+   for (std::mapint,int::const_iterator it = realintnum.upper_bound(15),
+  end = realintnum.end(); 
+  it != end; ++it) {
+ os  ,   it-first ;
}
os  )  std::ends;
 
@@ -161,11 +163,8 @@
   }
 
   if (!_old) {
-  for (i=0; i1024; i++)   // init index into int array
-   if (i  16) // first 16 map directly
-   realintnum[i] = i;
-   else
-   realintnum[i] = 0;
+  for (i=0; i16; i++) // Map first 16 interrupts directly
+realintnum[i] = i;
   intfile.ignore(1024, '\n');
   }
 



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

Bug#245282: dmsetup: So, please at least document --showkeys

[Michael Karcher]

Package: dmsetup
Version: 2:1.02.24-3
Followup-For: Bug #245282

While I agree on not documenting everything about possible mappings in
dmsetup, I am not happy about the lack of documentation of features dmsetup
itself provides, in this case, --showkeys.

A patch is included.

Regards,
  Michael Karcher

--- dmsetup.8.orig  2008-02-10 19:45:22.575103000 +0100
+++ dmsetup.8   2008-02-10 19:50:20.106261912 +0100
@@ -55,6 +55,7 @@
 .br
 .B dmsetup table
 .I [--target target_type]
+.I [--showkeys]
 .I [device_name]
 .br
 .B dmsetup wait
@@ -122,6 +123,9 @@
 specify a minimum value which will not be used if it is
 smaller than the value chosen by the kernel.
 None is equivalent to specifying zero.
+.IP \fB--showkews
+.br
+Do not hide encryption keys on the list command.
 .IP \fB--table\ table
 .br
 Specify a one-line table directly on the command line.
@@ -271,12 +275,14 @@
 device to remain unflushed.
 .IP \fBtable
 .I [--target target_type]
+.I [--showkeys]
 .I [device_name]
 .br
 Outputs the current table for the device in a format that can be fed
 back in using the create or load commands.
 With --target, only information relating to the specified target type
-is displayed.
+is displayed. Unless --showkeys is given, encryption keys of the crypt
+backend are replaced by an equal length string consisting only of zeroes.
 .IP \fBtargets
 .br
 Displays the names and versions of the currently-loaded targets.


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

Kernel: Linux 2.6.24-rc4 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dmsetup depends on:
ii  libc62.7-6   GNU C Library: Shared libraries
ii  libdevmapper1.02.1   2:1.02.24-3 The Linux Kernel Device Mapper use

dmsetup recommends no packages.

-- no debconf information



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

Bug#353494: Xserver SIGILL on processors without CPUID

[Michael Karcher]

Am Montag, den 24.12.2007, 23:28 +0100 schrieb Brice Goglin:
 Thank you very much for your input, I am going to forward all your 
 analysis in the upstream bug and I hope someone will be here to confirm 
 that you're right.
I got around to test a patched xserver on my 6x86 machine. The X server
works fine with this patch.

Surely this has been discussed multiple times: The nice thing about
debian stable is, that you can rely on all features and misfeatures in
it, so if you hacked a workaround for a bug that suddenly stops working
if the bug disappears, it will not stop working in debian stable. Of
course this policy has its merits.

But if a bug prevents the use of certain features completely, nothing
can be broken by fixing this bug, so a fix might be appropriate for
stable. Debian isn't doing it because of the philosophy of only adding
security updates to stable. Is there some third-party repository that
includes this kind of harmless bug fixes (I would call it something like
stable-recommended-updates), do you have any pointers to a discussion on
debian-devel about this subject?

Regards,
  Michael Karcher




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

Bug#353494: Xserver SIGILL on processors without CPUID

[Michael Karcher]

Package: xorg-server
Tags: patch

Hello,

this bug is uncorrelated to Cyrix CPUs. It is caused by an bad
expression in the MMX detection code. Apparently, gas changed the
handling of local labels, so jnz 1 does not assemble to the same as
jnz 1f, which it once did, IIRC. The documentation for gas does not
mention local labels without an f or b suffix. The attached patch
fixes the jump instructions in the inline assembly and thus this bug
(except for the last submitted message). The patch has not yet been
tested on the real hardware (first I have to recompile the xorg-server
package which I might not get around to before christmas), but the
obviously wrong x86 code in gdb's disassembly is gone.

Regards,
  Michael Karcher
--- xorg-server-1.1.1/fb/fbpict.c.orig	2007-12-24 10:37:26.0 +0100
+++ xorg-server-1.1.1/fb/fbpict.c	2007-12-24 10:37:50.0 +0100
@@ -1378,7 +1378,7 @@
  pop %%eax\n
  mov $0x0, %%edx\n
  xor %%ecx, %%eax\n
- jz 1\n
+ jz 1f\n
 
  mov $0x, %%eax\n
 	 push %%ebx\n
@@ -1422,7 +1422,7 @@
 cpuid\n
 xor %%edx, %%edx\n
 cmp $0x1, %%eax\n
-jge 2\n
+jge 2f\n
 mov $0x8001, %%eax\n
 cpuid\n
 2:\n

Bug#353494: Xserver SIGILL on processors without CPUID

[Michael Karcher]

Am Montag, den 24.12.2007, 15:58 +0100 schrieb Brice Goglin:
  this bug is uncorrelated to Cyrix CPUs. It is caused by an bad
  expression in the MMX detection code. Apparently, gas changed the
  handling of local labels, so jnz 1 does not assemble to the same as
  jnz 1f, which it once did, IIRC. The documentation for gas does not
  mention local labels without an f or b suffix. The attached patch
  fixes the jump instructions in the inline assembly and thus this bug

 Any idea why people would have seen the problem on Cyrix and not on 
 other CPUs?

The jump is only taken if CPUID is not present. The 6x68 CPUs are the
last ones where CPUID is not present (not enabled by some Cyrix-special
CPU configuration bit, in fact). Any Pentium has CPUID, the later Intel
486 (DX2 and upwards) has CPUID, any AMD processor since the 5x68 has
cpuid, so the later processors k5 and k6 do have cpuid.

   The patch has not yet been
  tested on the real hardware (first I have to recompile the xorg-server
  package which I might not get around to before christmas), but the
  obviously wrong x86 code in gdb's disassembly is gone.
 This code has moved to the pixman library since Xserver 1.4. And it 
 looks like the f suffix is there now. So if you are right, the bug 
 should be fixed in unstable already.
Any chance of getting the fix in the next point release? Probably not,
as it is not security related.

Regards,
  Michael Karcher




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

Bug#408562: joe: Bug is known upstream

[Michael Karcher]

Package: joe
Version: 3.5-1.1
Followup-For: Bug #408562

This bug is in the upstream bug tracker at
http://sourceforge.net/tracker/index.php?func=detailaid=1626910group_id=23475atid=378598
reported since 11 months now. A patch is present, which works. Please
apply in debian.

Regards,
  Michael Karcher

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

Kernel: Linux 2.6.23-rc1-hrt1 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages joe depends on:
ii  libc6 2.7-1  GNU C Library: Shared libraries
ii  libncurses5   5.6+20071013-1 Shared libraries for terminal hand

joe recommends no packages.

-- no debconf information



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

Bug#453310: joe: This bug is known upstream.

[Michael Karcher]

Package: joe
Version: 3.5-1.1
Followup-For: Bug #453310

This bug is in the upstream bug tracker at
http://sourceforge.net/tracker/index.php?func=detailaid=1626910group_id=23475atid=378598
reported since 11 months now. A patch is present, which works. Please
apply in debian.

Regards,
  Michael Karcher

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

Kernel: Linux 2.6.23-rc1-hrt1 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages joe depends on:
ii  libc6 2.7-1  GNU C Library: Shared libraries
ii  libncurses5   5.6+20071013-1 Shared libraries for terminal hand

joe recommends no packages.

-- no debconf information



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

Bug#455503: joe: No replace possible in german translation

[Michael Karcher]

Package: joe
Version: 3.5-1.1
Severity: normal
Tags: l10n

There is a bug reported twice in upstreams bug tracker, see
http://sourceforge.net/tracker/index.php?func=detailaid=1629477group_id=23475atid=378598
and
http://sourceforge.net/tracker/index.php?func=detailaid=1571991group_id=23475atid=378598
both time providing patches. This bug still applies and is quite
serious for german users. In the joe and WordStar mode, search/replace
is impossible if german translations are used. The provided .po file is
worse than no file at all. It does not contain any german translation, but
claims the english text to be the correct translation. It also contains
fuzzy translations that are plain wrong. So, please delete de.po from
the debian distribution, fix the most serious issue as indicated in
upstream bug #1571991 or take a quite good real translation file from
#1626910.

Thanks in advance,
  Michael Karcher

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

Kernel: Linux 2.6.23-rc1-hrt1 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages joe depends on:
ii  libc6 2.7-1  GNU C Library: Shared libraries
ii  libncurses5   5.6+20071013-1 Shared libraries for terminal hand

joe recommends no packages.

-- no debconf information



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

Bug#449395: unace-nonfree: Unace-Nonfree not 64-bit clean, but available for amd64

[Michael Karcher]

Package: unace-nonfree
Version: 2.5-2
Severity: important

Unace just does not work on x86_64/amd64 using the 64 bit version, but
the x86 (32-bit) package extracts the same ace archive out-of-the-box.
The problem is in source/base/all/declare.h, which needs a 64 bit patch
like the one applied to unace (the old, free version).

I will probably supply a patch this week, and attach it to this bug.

Regards,
  Michael Karcher

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

Kernel: Linux 2.6.23-rc1-hrt1 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages unace-nonfree depends on:
ii  libc6 2.6.1-1GNU C Library: Shared libraries
ii  libncurses5   5.6+20071013-1 Shared libraries for terminal hand

unace-nonfree recommends no packages.

-- no debconf information



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

Bug#436146: wodim: Prints hint to use dvd+rw-mediainfo on -msinfo invocation

[Michael Karcher]

Subject: wodim: Prints hint to use dvd+rw-mediainfo on -msinfo invocation
Package: wodim
Version: 9:1.1.6-1
Severity: normal

*** Please type your report below this line ***

wodim -msinfo dev=/dev/sr0 outputs on my system:

HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
0,0

The extra first line is confusing programs like gnomebaker, so multisession
disks cannot be created. I also consider it as quite useless in this case.

A patch that prints this hint only in verbose mode is attached.

Greetings,
  Michael Karcher

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

Kernel: Linux 2.6.23-rc1 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages wodim depends on:
ii  libc6 2.6-2  GNU C Library: Shared libraries
ii  libcap1   1:1.10-14  support for getting/setting POSIX.

Versions of packages wodim recommends:
ii  genisoimage   9:1.1.6-1  Creates ISO-9660 CD-ROM filesystem

-- no debconf information

--- cdrkit-1.1.6.orig/wodim/drv_mmc.c
+++ cdrkit-1.1.6/wodim/drv_mmc.c
@@ -1503,7 +1503,8 @@
dstat_t *dsp = dp-cdr_dstat;
 
struct track_info track_info;
-   printf(HINT: use dvd+rw-mediainfo from dvd+rw-tools for information 
extraction.\n);
+   if(lverbose)
+   printf(HINT: use dvd+rw-mediainfo from dvd+rw-tools for 
information extraction.\n);
/* if(getdisktype_mmc(usalp, dp)0)
return -1;
*/




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

Bug#360373: evolution: Also appears in 2.6.1

[Michael Karcher]

Package: evolution
Version: 2.6.1-2
Followup-For: Bug #360373

This problem also occurs in the version of evolution in sid, at least
with the library version my mixed system uses.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (930, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.17-rc1-g0e37e031-dirty
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages evolution depends on:
ii  dbus   0.61-5simple interprocess messaging syst
ii  evolution-data-ser 1.6.1-2   evolution database backend server
ii  gconf2 2.14.0-1  GNOME configuration database syste
ii  gnome-icon-theme   2.14.2-1  GNOME Desktop icon theme
ii  gtkhtml3.8 3.10.1-1  HTML rendering/editing library - b
ii  libart-2.0-2   2.3.17-1  Library of functions for 2D graphi
ii  libatk1.0-01.11.4-2  The ATK accessibility toolkit
ii  libaudiofile0  0.2.6-6   Open-source version of SGI's audio
ii  libavahi-client3   0.6.9-8   Avahi client library
ii  libavahi-common3   0.6.9-8   Avahi common library
ii  libavahi-glib1 0.6.9-8   Avahi glib integration library
ii  libbonobo2-0   2.14.0-1  Bonobo CORBA interfaces library
ii  libbonoboui2-0 2.14.0-2  The Bonobo UI library
ii  libc6  2.3.6-7   GNU C Library: Shared libraries
ii  libcairo2  1.0.4-2   The Cairo 2D vector graphics libra
ii  libcamel1.2-8  1.6.1-2   The Evolution MIME message handlin
ii  libcomerr2 1.37-2sarge1  common error description library
ii  libdbus-1-20.61-5simple interprocess messaging syst
ii  libdbus-glib-1-2   0.61-5simple interprocess messaging syst
ii  libebook1.2-5  1.6.1-2   Client library for evolution addre
ii  libecal1.2-3   1.6.1-2   Client library for evolution calen
ii  libedataserver1.2- 1.6.1-2   Utility library for evolution data
ii  libedataserverui1. 1.6.1-2   GUI utility library for evolution 
ii  libesd00.2.35-2  Enlightened Sound Daemon - Shared 
ii  libfontconfig1 2.3.1-2   generic font configuration library
ii  libfreetype6   2.1.10-3  FreeType 2 font engine, shared lib
ii  libgail-common 1.8.11-1  GNOME Accessibility Implementation
ii  libgail17  1.8.11-1  GNOME Accessibility Implementation
ii  libgconf2-42.14.0-1  GNOME configuration database syste
ii  libgcrypt111.2.2-1   LGPL Crypto library - runtime libr
ii  libglade2-01:2.5.1-2 library to load .glade files at ru
ii  libglib2.0-0   2.10.2-1  The GLib library of C routines
ii  libgnome-keyring0  0.4.9-1   GNOME keyring services library
ii  libgnome-pilot22.0.12-1.2Support libraries for gnome-pilot
ii  libgnome2-02.14.1-1  The GNOME 2 library - runtime file
ii  libgnomecanvas2-0  2.14.0-2  A powerful object-oriented display
ii  libgnomeprint2.2-0 2.12.1-3  The GNOME 2.2 print architecture -
ii  libgnomeprintui2.2 2.12.1-3  GNOME 2.2 print architecture User 
ii  libgnomeui-0   2.14.1-1  The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0 2.14.0-2  GNOME virtual file-system (runtime
ii  libgnutls131.3.5-1.1 the GNU TLS library - runtime libr
ii  libgpg-error0  1.2-1 library for common error values an
ii  libgtk2.0-02.8.16-1  The GTK+ graphical user interface 
ii  libgtkhtml3.8-15   3.10.1-1  HTML rendering/editing library - r
ii  libice64.3.0.dfsg.1-14sarge1 Inter-Client Exchange library
ii  libjpeg62  6b-10 The Independent JPEG Group's JPEG 
ii  libkrb53   1.4.3-7   MIT Kerberos runtime libraries
ii  libldap2   2.1.30-8  OpenLDAP libraries
ii  libnm-glib00.6.2-2   network management framework (GLib
ii  libnotify1 0.3.2-4   sends desktop notifications to a n
ii  libnspr4-0d1.8.0.1-8 NetScape Portable Runtime Library
ii  libnss3-0d 1.8.0.1-8 Network Security Service libraries
ii  liborbit2  1:2.14.0-1libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0  1.12.1-2  Layout and rendering of internatio
ii  libpisock8 0.11.8-22 Library for communicating with a P
ii  libpisync0 0.11.8-22 Synchronization library for PalmOS
ii  libpng12-0 1.2.8rel-1PNG library - runtime
ii  libpopt0   1.7-5 lib for parsing cmdline 

Bug#350743: libkexi-dev: kexidb/connection.h includes tristate.h instead of kexidb/tristate.h

[Michael Karcher]

Package: libkexi-dev
Version: 1:0.9-1+b1
Severity: normal

/usr/include/kde/kexidb/connection.h contains the line
#include tristate.h
which should include the provided tristate header file. The other
include directives indicate, that /usr/include/kde/kexidb is not
expected to be in the include path, so it should read
#include kexidb/tristate.h

Michael Karcher

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (930, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.15-rc4-g785a6436
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages libkexi-dev depends on:
ii  kexi  1:0.9-1+b1 tool for manipulating database obj

-- no debconf information


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

Bug#350743: libkexi-dev: kexidb/connection.h includes tristate.h instead of kexidb/tristate.h

[Michael Karcher]

Am Dienstag, den 31.01.2006, 15:40 + schrieb Martin Ellis:
 On Tuesday 31 January 2006 14:13, Michael Karcher wrote:
  /usr/include/kde/kexidb/connection.h contains the line
  #include tristate.h
  which should include the provided tristate header file. The other
  include directives indicate, that /usr/include/kde/kexidb is not
  expected to be in the include path, so it should read
  #include kexidb/tristate.h
 I don't think it should.  tristate.h is not kept in the kexidb directory in 
 source, so we won't be able to compile if we make this change.
OK, I looked at the source. This is definitely not a debian bug.

 tristate.h is only put into the kexidb dir to avoid polluting your 
 include/kde 
 dir.
But I would still consider this an upstream bug. Either the file is
named kexidb/tristate.h or it is named tristate.h. With both choices
it should be put at the right place, that
is /usr/include/kde/kexidb/tristate.h for the first case,
and /usr/include/kde/tristate.h in the second case.

 For now, please add both include/kde and include/kde/kexidb to include paths 
 to build against Kexi.
This will of course work, but I consider it as an ugly hack. 

 If you'd like to see an example of building against 
 Kexi using the installed headers, please see the external MS Access (MDB) 
 import plugin.
I see how they work around the problem using a lot of configure code. It
would be nice if just something along the lines of

oldcppflags=$CPPFLAGS
CPPFLAGS=$CPPFLAGS $KDE_INCLUDES
AC_CHECK_HEADER(kexidb/driver.h,KEXI_INCLUDE=$KDE_INCLUDES,
  [echo No kexi found, aborting;exit 1])
CPPFLAGS=$oldcppflags

would simply work.

Michael Karcher



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

Bug#350743: libkexi-dev: kexidb/connection.h includes tristate.h instead of kexidb/tristate.h

[Michael Karcher]

Am Dienstag, den 31.01.2006, 18:19 + schrieb Martin Ellis:
  I see how they work around the problem using a lot of configure code. It
  would be nice if just something along the lines of
 
  oldcppflags=$CPPFLAGS
  CPPFLAGS=$CPPFLAGS $KDE_INCLUDES
  AC_CHECK_HEADER(kexidb/driver.h,KEXI_INCLUDE=$KDE_INCLUDES,
[echo No kexi found, aborting;exit 1])
  CPPFLAGS=$oldcppflags
 
  would simply work.
 
 Why doesn't the above work?  What error do you get?

 As far as I'm concerned, the only thing needed is to add an extra directory 
 to  
 AM_CPPFLAGS in the Makefile.am (assuming using the KDE build system).

What should I put into the Makefile.am? The simple idea of
$(KEXI_INCLUDE)/kexidb what reduces to $(KDE_INCLUDES)/kexidb is not
guaranteed to work, as the substvar KDE_INCLUDES is empty if
kde_includes (note the lower case) is equal to x_includes or qt_includes
or to /usr/include. Can I rely on kde_includes to be a stable
interface that contains the path to the KDE headers even if they are in
a standard location, so that -I$(kde_includes)/kexidb will work?
If so, I will close the bug.

Michael Karcher



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