Bug#392983: X Error of failed request: BadMatch (invalid parameter attributes)

[allomber]

On Sat, Oct 14, 2006 at 11:40:31PM +0200, [EMAIL PROTECTED] wrote:
> On Sat, Oct 14, 2006 at 04:27:47PM +0200, Julien Danjou wrote:
> 
> Hello Julien,
> 
> > abydos ~ % koules
> > X4GW 1.21.21 professional
> > Copyright(c)1991,1992,1993,1994,1995 Jan Hubicka(JAHUSOFT)
> > Initializing sound server...
> > 2
> > Autoprobing hardware
> > Initializing joystick driver
> > Joystick driver: No such file or directory
> > Joystick 1 not avaiable..
> > Joystick driver: No such file or directory
> > Joystick 2 not avaiable..
> > Connecting X server
> > X: Screen doesn't support PseudoColor!
> 
> Your Visual does not support PseudoColor, this is not koules fault, even
> if PseudoColor support is rare this day, so I don't think this is RC 

Strike that, actually koules works fine in TrueColor.

> X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  146 (MIT-SHM)
>   Minor opcode of failed request:  3 (X_ShmPutImage)
>   Serial number of failed request:  306
>   Current serial number in output stream:  307

Please try to run 'xkoules -M', this disables use of MIT-SHM.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large blue swirl here. 


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

Bug#392983: X Error of failed request: BadMatch (invalid parameter attributes)

[allomber]

On Sat, Oct 14, 2006 at 04:27:47PM +0200, Julien Danjou wrote:

Hello Julien,

> abydos ~ % koules
> X4GW 1.21.21 professional
> Copyright(c)1991,1992,1993,1994,1995 Jan Hubicka(JAHUSOFT)
> Initializing sound server...
> 2
> Autoprobing hardware
> Initializing joystick driver
> Joystick driver: No such file or directory
> Joystick 1 not avaiable..
> Joystick driver: No such file or directory
> Joystick 2 not avaiable..
> Connecting X server
> X: Screen doesn't support PseudoColor!

Your Visual does not support PseudoColor, this is not koules fault, even
if PseudoColor support is rare this day, so I don't think this is RC 

You can check which the visuals your xserver support with xdpyinfo.

(Some programm cannot be ported to TrueColor or DirectColor because
they use the extra level of indirection that PseudoColor provides.
I don't know if it is the case here.)

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#392981: jtex-bin: purging the package fails (update-texmf unavailable)

[allomber]

On Sat, Oct 14, 2006 at 04:20:26PM +0200, Bill Allombert wrote:
> Package: jtex-bin
> Version: 1.9.1-7.1
> Severity: serious
> 
> Hello Masatoshi,
> 
> There is an error when attempting to purge jtex-bin:
>   Removing jtex-bin ...
>   Purging configuration files for jtex-bin ...
>   /var/lib/dpkg/info/jtex-bin.postrm: line 25: update-texmf: command not found
>   dpkg: error processing jtex-bin (--purge):
>subprocess post-removal script returned error exit status 127
> 
> The postrm script cannot rely on update-texmf to be available when purging.

There is the same problem in multex-bin:
  Removing multex-bin ...
  Purging configuration files for multex-bin ...
  /var/lib/dpkg/info/multex-bin.postrm: line 25: update-texmf: command not 
found  dpkg: error processing multex-bin (--purge):
   subprocess post-removal script returned error exit status 127

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#392948: tfm-arphic-bkai00mp: purging the package fails (kpsewhich unavailable)

[allomber]

On Sat, Oct 14, 2006 at 02:55:02PM +0200, Bill Allombert wrote:

> Package: tfm-arphic-bkai00mp
> Version: 2.11.2-0.1
> Severity: serious
> 
> Hello Anthony,
> 
> There is an error when attempting to purge tfm-arphic-bkai00mp:
>   Removing tfm-arphic-bkai00mp ...
>   Purging configuration files for tfm-arphic-bkai00mp ...
>   /var/lib/dpkg/info/tfm-arphic-bkai00mp.postrm: line 19: /usr/bin/kpsewhich: 
> No such file or directory
>   dpkg: error processing tfm-arphic-bkai00mp (--purge):
>subprocess post-removal script returned error exit status 1
> 
> The postrm script cannot rely on kpsewhich to be available when purging.

This bug also affect the following package, part of the same source,
tfm-arphic-bsmi00lp and tfm-arphic-gkai00mp.

  Removing tfm-arphic-bsmi00lp ...
  Purging configuration files for tfm-arphic-bsmi00lp ...
  /var/lib/dpkg/info/tfm-arphic-bsmi00lp.postrm: line 19: /usr/bin/kpsewhich: 
No such file or directory
  dpkg: error processing tfm-arphic-bsmi00lp (--purge):
   subprocess post-removal script returned error exit status 1
  Removing tfm-arphic-gkai00mp ...
  Purging configuration files for tfm-arphic-gkai00mp ...
  /var/lib/dpkg/info/tfm-arphic-gkai00mp.postrm: line 19: /usr/bin/kpsewhich: 
No such file or directory
  dpkg: error processing tfm-arphic-gkai00mp (--purge):
   subprocess post-removal script returned error exit status 1

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#359707: Status?

[allomber]

On Mon, Sep 04, 2006 at 05:28:25PM -0400, Laurence J. Lane wrote:
> On 9/4/06, Alan Woodland <[EMAIL PROTECTED]> wrote:
> 
> >What is the current status of this bug? Have you any plans to upload
> >0.9.4 soon? If you need any help preparing this upload feel free to give
> >me a shout - I'd like to see Eterm release with Etch.
> 
> Waiting on a diff from upstream for libscream's license change. It shouldn't
> be long at all. The package is ready to go besideds that.
> 
>   http://people.debian.org/~ljlane/stuff/eterm/

Hello Laurence,

One month has passed and the freeze get closer.
Did you make any progress ?

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#389738: otrs2: fails to install

[allomber]

On Wed, Sep 27, 2006 at 02:39:37PM +0200, Bill Allombert wrote:
> Package: otrs2
> Version: 2.0.4p01-14
> Severity: serious
> 
> Hello Torsten,
> 
> There is an error when attempting to install otrs2 (non interactively):
> 
>   Setting up otrs2 (2.0.4p01-14) ...
>   dbconfig-common: writing config to /etc/dbconfig-common/otrs2.conf
> 
>   Creating config file /etc/dbconfig-common/otrs2.conf with new version
> 
>   Creating config file /etc/otrs/database.pm with new version
>   error encountered creating user:
>   ERROR 2002 (HY000): Can't connect to local MySQL server through socket 
> '/var/run/mysqld/mysqld.sock' (2)
>   dbconfig-common: otrs2 configure: aborted.
>   dbconfig-common: flushing administrative password
>   dpkg: error processing otrs2 (--configure):
>subprocess post-installation script returned error exit status 1

Hello Torsten,
It has been pointed out to me that I have reported this bug in error, so I
am closing it.

Sorry for the trouble.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#316321: revisiting the "reload target" issue

[allomber]

On Tue, May 30, 2006 at 11:52:30PM +1000, Adam Conrad wrote:
> Pierre HABOUZIT wrote:
> >   Ping apache2-common maintainers ?
> >
> >   is there any reason why that bug is rotting in a RC state for 4+
> > monthes ?
> >
> >   I may perform an NMU soon.
> >   
> Yes, because I'm preparing a 2.0.58 upload which includes several
> patches to the init scripts, not just this one, so uploading just for
> this one bug would be reasonably pointless.
> 
> The RC bugs certainly matter for Etch's release (and will be fixed soon,
> so in plenty of time), but they don't much matter for sid->etch
> migration, since we're already up to date in Etch.

Hello Adam,

Two months has passed now, the Etch release draw nearer and this bug
is still open. May we expect an upload ?

It seems in retrospect that the NMU would not have been reasonably
pointless.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a \large red swirl here. 


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

Bug#359855: status report

[allomber]

On Wed, Aug 02, 2006 at 11:35:35AM -0700, Thomas Bushnell BSG wrote:
> 
> These bug will be closed certainly by the time lilypond 2.8 hits the
> archive; work is proceeding on that effort.
> 
> The bugs are RC bugs, but do not seem to be the sort that pose any
> actual inconvenience to anyone, so I don't intend to fix them in
> lilypond 2.6.  However, if this poses some inconvenience to someone,
> please let me know, explaining why it causes a problem, and I'll
> arrange an upload.

Hello Thomas, 
This bug is RC and the release come near.

At least this bug would prevent e.g. the security team to rebuild the
package after applying a security patch.

So please upload a fixed version.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#330604: Can you still reproduce this bug?

[allomber]

On Mon, Jul 17, 2006 at 08:36:11PM -0300, Margarita Manterola wrote:
> tags 330604 + moreinfo
> thanks
> 
> Hi!
> 
> In January you reported that you were having a problem with inkscape:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330604
> 
> Can you still reproduce this bug?
> 
> I have tested inkscape both on amd64, and etch i386 and sid i386 and it
> works fine. So, please say if you still can reproduce the bug, and if you
> can, how you do it.

Hello Margarita,

I suggest you try to run inkscape under valgrind.

Here that cause a segfault even though it run fine outside 
valgrind (on i386).

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#351693: guile-1.6: builds on ia64, but causes other packages to FTBFS?

[allomber]

tags 351693 fixed
quit

On Wed, May 31, 2006 at 06:08:06PM -0700, Steve Langasek wrote:
> I see that guile-1.6 1.6.8-2 has now built successfully on ia64 (congrats!),
> but it looks like the first package to try to build *against* it, g-wrap,
> now fails with an error that looks like it's also a guile-1.6 problem:
> 
> [...]
> /usr/bin/make  check-TESTS
> make[4]: Entering directory `/build/buildd/g-wrap-1.9.6/guile/test'
> /bin/sh: line 4: 23120 Illegal instruction ${dir}$tst
> FAIL: test-standard
> /bin/sh: line 4: 23125 Illegal instruction ${dir}$tst
> FAIL: test-enumeration
> /bin/sh: line 4: 23130 Illegal instruction ${dir}$tst
> FAIL: test-wct
> /bin/sh: line 4: 23135 Illegal instruction ${dir}$tst
> FAIL: test-compat
> ===
> 4 of 4 tests failed
> ===
> [...]
> 
> http://buildd.debian.org/fetch.php?pkg=g-wrap&arch=ia64&ver=1.9.6-3&stamp=1149122954&file=log

Hello Steve and Thomas, as far as I understand, this bug was fixed by
this release of guile-1.6.
  
guile-1.6 (1.6.8-4) unstable; urgency=low

  * Add upstream fix for continuations crash on ia64. (closes: #291551)

 -- Rob Browning <[EMAIL PROTECTED]>  Wed, 19 Jul 2006 23:43:07 -0700

Indeed both guile-1.6 and g-wrap built fine on ia64.

So I am marking this bug as fixed.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared

[allomber]

On Wed, Jun 28, 2006 at 12:58:59AM +0200, Alexander Schmehl wrote:
> [ Cc-ing the bug report, so we have it in the bts, too ]
> 
> Hi!
> 
> - Now the real problem: shc.c
> 
> Lookit at it we have:
> 
> /**
>  * This software contains the 'Alleged RC4' source code.
>  * The original source code was published on the Net by a group of 
> cypherpunks.
>  * I picked up a modified version from the news.
>  * The copyright notice does not apply to that code.
>  */

As far as I remember, the general belief is that 'Alleged RC4' was in
fact leaked intentionnaly by RSA inc. itself (which designed RC4).  So
much for the group of cypherpunks.

> /**
>  * 'Alleged RC4' Source Code picked up from the news."
>  * From: [EMAIL PROTECTED] (John L. Allen)"
>  * Newsgroups: comp.lang.c"
>  * Subject: Shrink this C code for fame and fun"
>  * Date: 21 May 1996 10:49:37 -0400"
>  */

I think it should be easy to replace that code by a DFSG-free
implementation of RC4. Openssl include one.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#375300: new tar behavior and --wildcards

[allomber]

On Mon, Jun 26, 2006 at 01:22:12PM -0600, Bdale Garbee wrote:
> 
> Since this seems to have been an intentional behavior change by
> upstream to better align with a published standard, I'm uninclined to
> fight it, and think our best response is to update our utilities to
> include the --wildcards option, with a suitable versioned dependency on
> tar.

Debian still has to provide an upgrade path for users upgrading from Sarge.
We cannot blindly break users scripts.

Also, before doing such change we need to audit:

1) all build scripts (i.e. rebuild the whole archive with the new tar)
   and see how many packages FTBFS.
2) all Sarge maintainer scripts, init script and cron scripts
3) all Etch  maintainer scripts, init script and cron scripts
4) all Sarge packages for tar usage to allow for partial upgrade.
5) all Etch packages for tar usage 

We did something similar with "su" but we did it earlier in the release
cycle, and I think we have already lot of work to do to release etch on
time.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#372576: monodevelop requires libmono-cecil3.0-cil but libmono-cecil4.0-cil is installed

[allomber]

fixed 372576 0.10-2
quit

On Sat, Jun 10, 2006 at 01:18:37PM +0200, Xavier Queralt Mateu wrote:
> Package: monodevelop
> Version: 0.10-1
> Severity: important
> 
> Monodevelop package depend on libmono-cecil3.0-cil but apt changes it for 
> libmono-cecil4.0-cil which don't let you run monodevelop.
> 
> I suggest the two packages live together untill monodevelop runs with 
> libmono-cecil4.0-cil.

Hello Xavier,
This problem has been fixed in version 0.10-2.
monodevelop now depends on libmono-cecil0.4-cil.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#374160: apache2 does not build with apt-build

[allomber]

On Sat, Jun 17, 2006 at 05:25:25PM +0200, Stefan Hirschmann wrote:
> Package: apache2
> Version: 2.0.55-4
> Severity: serious
> Justification: no longer builds from source
> 
> I ran apt-build --rebuild --reinstall install apache2 
> and got this error:
> .
> dh_clean
> Error while building apache2!
> Sorry, no package to install.

I confirm the FTBFS: I tried to build apache2 2.0.55-4 with pbuilder and
it also failed:

libtool: install: warning: 
`/tmp/buildd/apache2-2.0.55/build-tree/apache2-build/perchild/srclib/apr-util/libaprutil-0.la'
 has not been installed in `/usr/local/apr/lib'
libtool: install: warning: 
`/tmp/buildd/apache2-2.0.55/build-tree/apache2-build/perchild/srclib/apr/libapr-0.la'
 has not been installed in `/usr/local/apr/lib'
/usr/bin/install .libs/apache2 
/tmp/buildd/apache2-2.0.55/debian/apache2-mpm-perchild/usr/sbin/apache2
dh_testroot
mv debian/apache2-mpm-worker/usr/include/apache2/apr* 
debian/libapr0-dev/usr/include/apr-0
mv: cannot stat `debian/apache2-mpm-worker/usr/include/apache2/apr*': No such 
file or directory
make: *** [debian/stampdir/move] Error 1

The full build-log is here:



Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#334407: gbib segfaults after update

[allomber]

tags 334407 fixed
quit

On Wed, Oct 19, 2005 at 02:05:01PM -0700, Steve Langasek wrote:
> On Tue, Oct 18, 2005 at 10:15:45PM +0200, Philipp Frauenfelder wrote:
> > Am Mon, Oct 17, 2005 at 10:38:09PM -0700 hat Steve Langasek getippert:
> > > Two people have tried and failed to reproduce this problem on an 
> > > up-to-date
> > > sid system.
> 
> > Same for me. If I set up an up-to-date chroot of sid, the
> > problem is not reproducible. I guess upgrading the right library
> > will fix the problem.
> 
> Hmm, ok.  I also can't reproduce the problem in testing, and the valgrind
> output doesn't point to any errors in gbib itself, so I guess this is a
> transient library problem and the bug should be closed?

I could not reproduce the problem either, so I am to agree with your
assessement and tags the bug fixed.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#337358: Bug#337346: slib upgrade broken

[allomber]

Hello Rob and Thomas,

This bug is assigned to libglade9 which has been removed from 
unstable.

As a consequence, this bug should either be closed or reassigned.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#343599: (no subject)

[allomber]

On Fri, Dec 16, 2005 at 03:07:04PM +0100, Michael Banck wrote:
> On Fri, Dec 16, 2005 at 02:53:19PM +0100, Gregoire Masliah wrote:
> > the version of ghemical i've attempted to install is 1.01-2
> 
> I have requested a rebuild for the amd64 archive which should make
> ghemical installable on stable/amd64 again.

Hello Michael,
what is the status of this bug ?
It seems it should be tagged stable or closed, but it does not affect
etch.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#358746: Fixed in NMU of mcrypt 2.6.4-3.1

[allomber]

tag 340008 - fixed
tag 358746 + fixed
quit
On Tue, Jun 06, 2006 at 06:02:13AM -0700, Steinar H. Gunderson wrote:
> 
> Changes: 
>  mcrypt (2.6.4-3.1) unstable; urgency=low
>  .
>* Non-maintainer upload.
>* Hack around other libraries #undef-ing VERSION by creating a duplicate
>  variable MCRYPT_VERSION in configure.in and config.h, rerunning autoconf,
>  and using that in src/mcrypt.c; fixes FTBFS. (Closes: #340008)

It seems you closed 340008 instead of 358746. 

I would suggest replacing your numberpad...

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#350688: gcc-2.95: FTBFS with new make

[allomber]

On Tue, Jan 31, 2006 at 12:03:40PM +0100, Matthias Klose wrote:
> please send a fix. I do not intend to touch this code. it's fixed in
> the 3.4, 4.0 and 4.1 packages.

Hello Matthias,

Daniel and Matt Krai provided a patch for this bug.
Do you plan to upload this package soon ?

In the alternative, would you consider the option of a NMU ?

Thanks in advance fro your answer,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#327049: wwwoffle: Restores removed conffile

[allomber]

On Wed, Apr 05, 2006 at 06:21:45PM +0200, Paul Slootman wrote:
> My problem is with the wording of your bug report, you demand the file
> mustn't be recreated. If you now qualify that by saying that if the user
> does indeed enter a frequency again then it's OK to recreate the file,
> then I indeed don't have a problem anymore.
> 
> > >> I'd offer to write a patch if you don't want to, or don't have time to
> > >> dig into this.
> > >
> > > If you could take into account all possible situations... then please.
> > > Note that I am in the process of packaging 2.9, and the maintainer
> > > script will be changed a lot (I'm taking out support for upgrading from
> > > before woody, which will simplify things and which should be more than
> > > enough).
> > 
> > Is the new maintainer script available somewhere?
> 
> Not yet.

Hello Paul, what is the status with this package ?
As a result of this problem, wwwoffle has been removed from testing.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#369877: kaffe FTBFS on ia64

[allomber]

On Fri, Jun 02, 2006 at 12:06:06AM +0200, Bill Allombert wrote:
> Package: kaffe
> Version: 2:1.1.7-2
> Severity: serious
> 
> Hello Kaffe maintainers,
> 
> kaffe FTBFS on ia64:
> 
> make[4]: Leaving directory 
> `/build/buildd/kaffe-1.1.7/build/jthreads/libraries/javalib/external/classpath/lib'
> make[3]: *** [all-recursive] Error 1
> 
> The full buildlog is available at:
> http://buildd.debian.org/fetch.php?pkg=kaffe&ver=2:1.1.7-2&arch=ia64&stamp=1148911129&file=log

Hello Kaffe maintainers,
while investigating, I found the following:

1) kaffe build-depend on 
Build-Depends: ecj-bootstrap (>= 3.1.2-4), ecj-bootstrap-gcj (>=
3.1.2-4) [alpha arm hppa i386 ia64 powerpc s390 sparc]

2) debian/rules do
CONFFLAGS   += --with-ecj=/usr/bin/ecj

3) /usr/bin/ecj is an alternative provided by both ecj-bootstrap and
ecj-bootstrap-gcj.

4) kaffe build fine on ia64 if /usr/bin/ecj point to ecj-bootstrap,
but FTBFS if it point on ecj-bootstrap-gcj.

5) kaffe build fine on amd64 in both case (even though kaffe does not
build-depend on ecj-bootstrap-gcj onthat plateform).

So at the very least you can fix this bug by forcing the use
of ecj-bootstrap on ia64.

I am not quite sure what 1) is supposed to achieve: what is the point of
requiring two versions of ecj and using only one of them randomly (where
/usr/bin/ecj points to is a local setting) ? It looks like I missed
something.

However, on the face of it, the failure to build this package is a bug in
ecj-bootstrap-gcj on ia64.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#368310: upstream; to be fixed in 4.2.1

[allomber]

On Wed, May 24, 2006 at 01:26:21AM -0400, Steve M. Robbins wrote:
> Hi,
> 
> Just to note: a new upstream version 4.2.1 is at "release candidate"
> status.  I have alerted upstream about this problem and expect that it
> will be addressed in the next upstream release.  I'll leave it until
> then.

Hello Steve,

according to , version 4.2.1 was released on
2006-05-04.  In any case, 4.2.1 is available now and seems to fix this
bug.

Any ETA for an upload ?

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#368580: expect 5.43.0-3 dynamically linked but libexpect missing

[allomber]

tags 368580 fixed
merge 368580 368364
quit

On Tue, May 23, 2006 at 07:23:48PM +1000, Brian Keck wrote:
> expect 5.43.0-3 is dynamically linked (unlike 5.43.0-2) but lacks
> libexpect:
> 
> % ar xf /home/debian/pool/main/e/expect/expect_5.43.0-3_i386.deb
> % tar xzf data.tgz
> % ldd usr/bin/expect 
> libexpect5.43.so => not found
> ...
> % ls usr/lib
> expect5.43

Hello Brian,

This bug is a duplicate of 368364 which was fixed in expect version
expect_5.43.0-3.1.

Thanks for your bug report,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#367618: [PATCH] Re: #367618: libexpect5.43.so: cannot open shared object file: No such file or directory

[allomber]

On Sat, May 20, 2006 at 09:09:22AM +0100, Paul Cupis wrote:
> tag 367618 + patch
> thanks
> 
> Please find attached my patch which moves libexpect5.43.so back into the
> expect package.
> 
> expect-dev Depends on expect, so the shared object will available to
> link with (re: bug #367325).

Well the real fix would be to package the library following Debian
policy...

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#284770: Bug #284770: dbmail: FTBFS (amd64/gcc-4.0): invalid lvalue in assignment

[allomber]

On Sun, Oct 30, 2005 at 11:00:30PM +0100, Paul J Stevens wrote:
> 
> Hi Rob,
> 
> Thanks for taking an interest. Both bugs have long since been fixed in the
> debian packages for dbmail I maintain at debian.nfgd.net. Since preparing the
> 1.2 packages I've become heavily involved in upstream devel. There are other
> more serious problems with 1.2 which are more serious imo (read sql 
> injection),
> and have long since been fixed by me and others in the 2.0 tree.
> 
> If you want to nmu please do! Becoming a dm is not a motive anymore for 
> working
> on dbmail. Packages for sarge/edge for dbmail-2.0 are available for nmu.
> Experimental packages are also available for the as yet to be released
> dbmail-2.2 packages.

Hello Paul,

You tagged this bug "fixed-upstream pending" six week ago.
Did you hit problems with uploading the new packages ? 

We really need this bug to be fixed soon.

Thanks in advance,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#329212: fisg: Fisg segfault

[allomber]

On Wed, Sep 21, 2005 at 10:54:04AM +0200, Alexander Wirt wrote:
> Sythos schrieb am Mittwoch, den 21. September 2005:
> 
> > On Wed, Sep 21, 2005 at 10:35:06AM +0200, Alexander Wirt wrote:
> > > > Package: fisg
> > > > Version: 0.3.8-2
> > > > Severity: grave
> > > > Justification: renders package unusable
> > > > fisg segfault while parsing file, strace output attached
> > > Are you able to give me the correspondending logfile that has segfaultet?
> > > Thanks for your report
> > 
> > sure (it is about 5min log from eggdrop test)
> Thanks. 
> It looks like that the logfile parsing code is bad. If I add the "--format
> eggdrop" switch it parses (it still has some problems because no configfile is
> used, but it outputs an html site...). I should check the status of the
> actual cvs version, but I have to talk to the author first it its useable. 

Hello Alexander,
This buglog include a patch that should fix this bug.  On the other
hand, fisg web site says that FISG project has been terminated, and
pisg replace it.

So please either upload a fixed version, or ask for removal of fisg
from unstable. I offer to NMU fisg if you want.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#359854: doesn't detect recv()=0

[allomber]

On Sat, Apr 01, 2006 at 08:55:30AM -0400, Bruno Barrera C. wrote:
> > I would seriously reconsider maintenance of this package..trivially
> > fixed valgrind warnings, saved files aren't correct, overwrites files
> > which wget wouldn't, and improper use of recv.
> 
> Could you please explain me what does "reconsider maintenance of this
> package" means? Are referering to my work or upstream?. FYI, I've
> written a lot of patches for aget and sent it directly to upstream as
> you can see in the bug reports before. 
> 
> Sadly, upstream is a bit slow replying and that's why I don't want to
> make this package fully of patches, because is a small program and we
> can introduce changes directly to the official source code.

Hello Bruno,
This package has been removed from Etch.

So either you think aget is suitable for Debian and upload a fixed
version soon, or you think it is not and ask for remove from unstable.

Thanks in advance,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#339060: abntex: FTBFS: \pdfinfo used while \pdfoutput

[allomber]

On Fri, Nov 25, 2005 at 05:55:07PM +0100, Frank Küster wrote:
> Roland Stigge <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > building the package abntex in a clean sid build environment
> > (with pbuilder) on i386 results in:
> [...]
> > pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
> > l.75 \pdfinfo
> 
> The reason is a buggy test whether pdf or dvi is produced - it was buggy
> from the beginning, but is no longer tolerated in teTeX-3.0.  The
> particular place where the package fails is this one:
> 
> When you fix this, or propose a fix to upstream, please do *not* simply
> test whether pdfoutput is 0 or 1.  Instead, use ifpdf or the code
> therein - otherwise adding a package that also checks for \pdfoutput
> might cause problems.

Hello Otavio, Roland and Frank,

Upstream has release 0.9-beta which seems to fix this bug albeit
differently (they no more use \pdfoutput at all).

However the new version need the file
/usr/share/texmf/tex/latex/html/html.sty 
(from latex2html which is currently in non-free) to build.

Is there a way to avoid using this file ?

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 

Bug#304066: #304066: conffile prompt is probably fixed but bug isn't closed

[allomber]

tags 304066 fixed
quit
On Sun, Mar 26, 2006 at 11:24:27AM -0500, Justin Pryzby wrote:
> This problem seems to have been "fixed" by modifying the conffile in
> sid to be the same as the one in sarge.  This isn't a very good
> solution, because you might decide that you actually want to both
> change the contents of the conffile between stable releases, and
> change the package owning the conffile.  But anyway.

Especially since you might decide to change the conffile one year after
the rename when you have completly forgotten about the issue...

> I'm not going to close this bug, on the premise that this is the
> maintainers responsibility, and they should really bother to respond
> to their bugs (even if they are not "release critical"), and care if
> their package is in testing or not.

Well I cannot reproduce this bug with piuparts so I am tagging this bug 
fixed in the meantime. I suppose there are simply too much maintainers for
this package.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#349675: gparted: Missing dependency on package libparted1.6-13 on AMD64

[allomber]

On Wed, Jan 25, 2006 at 12:52:22AM +1100, Andree Leidenfrost wrote:
> Package: gparted
> Version: 0.0.9-1
> Severity: serious
> Justification: Policy 3.5
> 
> Hi David,
> 
> gparted fails to start with the following error:
> 
> gparted-bin: error while loading shared libraries: libparted-1.6.so.13: 
> cannot open shared object file: No such file or directory
> 
> Installing package libparted1.6-13 fixes the problem.

Hello Andree,
Could you retry with the "official" amd64 package from ftp.debian.org ?

The "official" package depends on libparted1.6-13 so this problem
should not happen.

> When building the gparted package, I get:
> 
> dh_shlibdeps
> dpkg-shlibdeps -Tdebian/gparted.substvars 
> debian/gparted/usr/bin/gparted-bin
> dpkg-shlibdeps: warning: could not find any packages for 
> /usr/lib/libparted-1.6.so.13 (libparted-1.6.so.13)
> dpkg-shlibdeps: warning: unable to find dependency information for 
> shared library libparted-1.6 (soname 13, path 
> /usr/lib/libparted-1.6.so.13, dependency field Depends)

The gparted amd64 buildlog 

does not show such warning.

> So, it looks like dh_shlibdeps lloks for the the libparted library in 
> /usr/lib but the package has it in /lib. The latter might be wrong, not 
> sure.

dpkg-shlibdeps does not take the path into account, so this seems rather
that the shlibs file was missing.

However the current official amd64 libparted1.6-13 package carry a correct
shlibs file so it seems this issue has been dealt with.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#331661: extensions/*.jar ship without source code, shipped jar files are installed

[allomber]

On Fri, Apr 21, 2006 at 03:02:10PM +0200, [EMAIL PROTECTED] wrote:
> On Fri, Mar 17, 2006 at 04:59:05PM -0800, Don Armstrong wrote:
> Hello Mark,
> 
> docbook-xsl include the following jar files in the extensions directory:
> 
> saxon643.jar  saxon651.jar  saxon653.jar  xalan25.jar
> saxon644.jar  saxon652.jar  saxon65.jar
> 
> Some source code is only provided for saxon643 and xalan25.
> 
> Only saxon65.jar, saxon651.jar and xalan25.jar are currenlty shipped in
> the .deb file.
> 
> The version of libsaxon-java in Debian is 6.5.5 and xalan is 2.6.0.
> 
> Given that the jar files are not essential to the packages, and given
> your current level of involvement in maintaining it, I would suggest we
> take the simpler route of 2. above.
> 
> This means to build a new "upstream" tarball 1.68.1.dfsg.1 
> (or eventually 1.69.1.dfsg.1 since docbook-xsl-1.69.1 was released) 
> that does not include the extensions directory, and remove reference 
> to theses extensions in the packaging.
> 
> For that purpose, I have made suitable packages available at
> .
> I attach the output of debdiff minus the removal of the extensions
> directory.
> 
> Given that this RC bug is 6 months old, we need to fix it soon, so
> I would appreciate an answer in less than a week.

Hello Mark,

Unless I hear from you, I plan to upload the above packages soon now.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>
 
Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Bug#320375: conquest-gl: fail to start (Assertion `window->Window.VisualInfo != ((void *)0)' failed.)

[allomber]

On Fri, Apr 21, 2006 at 07:34:32PM +0200, Bill Allombert wrote:
> Once upgrading (only) freeglut3 to 2.4.0-5, I get
> freeglut (conquestgl):  ERROR:  Internal error  capabilities not found> in function fgOpenWindow
> X Error of failed request:  BadWindow (invalid Window parameter)
>   Major opcode of failed request:  4 (X_DestroyWindow)
>   Resource id in failed request:  0x0
>   Serial number of failed request:  29
>   Current serial number in output stream:  33
> 
> Once upgrading (only) conquest-gl to 8.1.2-2 I get
> 
> conquestgl: symbol lookup error: conquestgl: undefined symbol: dspInitData

After upgrading conquest-libs to 8.1.2-2 I get:

freeglut (conquestgl):  ERROR:  Internal error  in function fgOpenWindow
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  4 (X_DestroyWindow)
  Resource id in failed request:  0x0
  Serial number of failed request:  23
  Current serial number in output stream:  26

So it seems conquest-gl need a versionned dependency on conquest-libs
(or conquest-libs shlibdeps should be bumped) to allow for partial
upgrades.

The code before this error:
GL.c:962

  glutInit(argc, argv);
  glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | GLUT_ALPHA);

  glutInitWindowPosition(0,0);

  glutInitWindowSize(dConf.initWidth, dConf.initHeight);

  dConf.mainw = glutCreateWindow(CONQUESTGL_NAME);

Removing GLUT_ALPHA from glutInitDisplayMode in this file allow to 
bypass the error message and get a window. (I am not sure whether
conquestgl really work but it does not crash).

According to the OPENGL GLUT spec: 

   GLUT_ALPHA
  Bit mask to select a window with an alpha component to the
  color buffer(s).

So Jamie, does the error means that my GL driver does not support 
alpha transparency, or is it a bug in freeglut ? 

You can try the testcase I attached.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 
#include 
#include 
#include 
#include 
#define CONQUESTGL_NAME "conquest"

int uiGLInit(int *argc, char **argv)
{

  glutInit(argc, argv);
  glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | GLUT_ALPHA);

  glutInitWindowPosition(0,0);

  glutInitWindowSize(400, 300);
  
  glutCreateWindow(CONQUESTGL_NAME);

  return 0; 
}

/*  conquest - main program */
int main(int argc, char *argv[]) 
{
  uiGLInit(&argc, argv);
  return 0;
}

Bug#331661: extensions/*.jar ship without source code, shipped jar files are installed

[allomber]

On Fri, Mar 17, 2006 at 04:59:05PM -0800, Don Armstrong wrote:
> On Tue, 04 Oct 2005, Mark Johnson wrote:
> 
> > Matthias Klose wrote:
> > >Package: docbook-xsl
> > >Version: 1.68.1
> > >Severity: serious
> > >
> > >The extensions contains many jar files, without having the sources in
> > >the source package, the problematic files seem to be:
> > >
> > >  saxon644.jar
> > >  saxon65.jar
> > >  saxon651.jar
> > >  saxon652.jar
> > >  saxon653.jar
> > 
> > I don't change what comes in the upstream source package.
> 
> That's fine, but the proper approach here is to either build these
> files from the source code if that's available, or remove them
> entirely and rebuild the orig.tar.gz as 1.68.1.dfsg.orig.tar.gz or
> similar.
> 
> > >It looks like the source for saxon643.jar and xalan25.jar is provided,
> > >but they are not built during the build process.
> > 
> > If docbook-xsl is now going to require a rebuild of the (supposedly)
> > portable jars, then we need to rethink how to package this stuff.
> 
> Considering the fact that you can't currently fix any bugs in those
> jars, yes, that's pretty much what it means.
> 
> Regardless, for this bug there are three alternatives:
> 
> 1: Ship the source code for the jars (and build the jars from it)
> 
> 2: Strip out the jars and distribute as a .dfsg package
> 
> 3: Remove docbox-xsl from the archive.
> 
> Please enact one of them so this bug can be resolved.

Hello Mark,

docbook-xsl include the following jar files in the extensions directory:

saxon643.jar  saxon651.jar  saxon653.jar  xalan25.jar
saxon644.jar  saxon652.jar  saxon65.jar

Some source code is only provided for saxon643 and xalan25.

Only saxon65.jar, saxon651.jar and xalan25.jar are currenlty shipped in
the .deb file.

The version of libsaxon-java in Debian is 6.5.5 and xalan is 2.6.0.

Given that the jar files are not essential to the packages, and given
your current level of involvement in maintaining it, I would suggest we
take the simpler route of 2. above.

This means to build a new "upstream" tarball 1.68.1.dfsg.1 
(or eventually 1.69.1.dfsg.1 since docbook-xsl-1.69.1 was released) 
that does not include the extensions directory, and remove reference 
to theses extensions in the packaging.

For that purpose, I have made suitable packages available at
.
I attach the output of debdiff minus the removal of the extensions
directory.

Given that this RC bug is 6 months old, we need to fix it soon, so
I would appreciate an answer in less than a week.

Thanks in advance for your answer,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 
--- /tmp/fLIl0ufi4X/docbook-xsl-1.68.1/debian/changelog 2006-04-21 
14:52:35.435580543 +0200
+++ /tmp/r6LC92U742/docbook-xsl-1.68.1.dfsg.1/debian/changelog  2006-04-21 
14:52:35.748570387 +0200
@@ -1,3 +1,12 @@
+docbook-xsl (1.68.1.dfsg.1-0.1) unstable; urgency=low
+
+  * NMU
+  * new "upstream" tarball: 
+- remove xalan & saxon extensions we are missing the source for.
+  * remove reference to these extensions.
+
+ -- Bill Allombert <[EMAIL PROTECTED]>  Thu, 20 Apr 2006 23:10:09 +
+
 docbook-xsl (1.68.1-0.1) unstable; urgency=low
 
   * NMU: latest version.
--- /tmp/fLIl0ufi4X/docbook-xsl-1.68.1/debian/control   2006-04-21 
14:52:35.435580543 +0200
+++ /tmp/r6LC92U742/docbook-xsl-1.68.1.dfsg.1/debian/control2006-04-21 
14:52:35.748570387 +0200
@@ -19,8 +19,7 @@
  processed to a number of print formats using FOP or TeX-based tools.
  .
  The stylesheets are modular in the sense that you can extend and, to some
- extent, customize them. Included are extension classes for the Saxon and 
Xalan2
- XSLT processors. The documentation is included in this package.
+ extent, customize them. The documentation is included in this package.
  .
  Authors:  Norman Walsh <[EMAIL PROTECTED]> and docbook-developers at 
Sourceforge
  .
--- /tmp/fLIl0ufi4X/docbook-xsl-1.68.1/debian/docbook-xsl.install   
2006-04-21 14:52:35.437580478 +0200
+++ /tmp/r6LC92U742/docbook-xsl-1.68.1.dfsg.1/debian/docbook-xsl.install
2006-04-21 14:52:35.749570355 +0200
@@ -12,6 +12,3 @@
 template   usr/share/xml/docbook/stylesheet/nwalsh/
 xhtml  usr/share/xml/docbook/stylesheet/nwalsh/
 VERSIONusr/share/xml/docbook/stylesheet/nwalsh/
-debian/docbook-xsl-saxon65-1.68.1.jar   usr/share/java
-debian/docbook-xsl-saxon651-1.68.1.jar  usr/share/java
-debian/docbook-xsl-xalan25-1.68.1.jar   usr/share/java
--- /tmp/fLIl0ufi4X/docbook-xsl-1.68.1/debian/docbook-xsl.links 2006-04-21 
14:52:35.437580478 +0200
+++ /tmp/r6LC92U742/docbook-xsl-1.68.1.dfsg.1/debian/docbook-xsl.links  
1970-01-01 01:00:00.0 +0100
@@ -1,6 +0,0 @@
-usr/share/java/docbook-xsl-saxon65-1.68.1.jar  
usr/share/java/docbook-xsl-saxon65.jar
-usr/share/java/docbook-xsl-saxon653-1.68.1.jar 
usr/share/java/docbook-xsl-saxon653.jar
-usr/share/java/docbook-xsl-xalan25-1.68.1.jar  
usr/share/java/docbo

Bug#349807: towitoko: [m68k, arm, s390] FTBFS: cp: cannot stat `./debian/tmp/usr/lib/libtowitoko.so': No such file or directory

[allomber]

On Wed, Jan 25, 2006 at 02:04:00PM +0100, Simon Richter wrote:
> Hi,
> 
> Christian T. Steigies wrote:
> 
> >cp: cannot stat `./debian/tmp/usr/lib/libtowitoko.so': No such file or 
> >directory
> >dh_install: command returned error code 256
> 
> This appears to be the libtool bug with the missing ".so", probably a 
> side-effect of the libtool version bump.

FYI, this problem also occurs on i386 (according to pbuilder) and
x86_64, see 
http://buildd.debian.org/build.php?&pkg=towitoko&ver=2.0.7-7&arch=amd64&file=log
, so this is a totally RC bug.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#290329: uname -m not dpkg-architecture

[allomber]

On Thu, May 26, 2005 at 01:58:38PM +0100, Alex Owen wrote:
> 
> Just thinking some more about my proposed fix... using
> dpkg-architecture would mean "Require: dpkg-dev" but the idea could
> perhaps be reworked to use "uname -m" which is in coreutils which is:
> 
> $ apt-cache show coreutils
> Package: coreutils
> Essential: yes
> Priority: required
> Section: base
> .
> 
> Not sure what a powerpc machine outputs for "uname -m" though...

You can use
dpkg --print-installation-architecture
which _does not_ require dpkg-dev.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#300417: CAN-2005-0664: DoS and possibly execute arbitrary code

[allomber]

On Sat, Mar 19, 2005 at 05:22:28PM +0100, Helge Kreutzmann wrote:
> Package: libexif5
> Version: N/A; reported 2005-03-19
> Severity: grave
> Tags: security, woody
> Justification: user security hole
> 
> Please see
> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0664
> 
> If libexif5 is not impacted then please add CAN-2005-0664 to
> http://www.debian.org/security/nonvulns-woody

Upstream have provided a patch for 0.6.12 below:
 
http://sourceforge.net/tracker/download.php?group_id=12272&atid=312272&file_id=124506&aid=1158402

<--- libexif-0.6.12/libexif/exif-data.c.xx  2005-03-07 13:39:31.512343466 
+0100
<+++ libexif-0.6.12/libexif/exif-data.c 2005-03-07 13:40:34.916416519 +0100
<@@ -696,7 +696,7 @@
< "Found EXIF header.");
< 
<   /* Byte order (offset 6, length 2) */
<-  if (ds < 12)
<+  if (ds < 14)
<   return;
<   if (!memcmp (d + 6, "II", 2))
<   data->priv->order = EXIF_BYTE_ORDER_INTEL;
<
However this patch does not apply to 0.5.0 in woody.

Reading the source code, woody is vulnerable and the patch below
should fix the problem. (The code is very similar at this point
but size was renamed to ds).

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


--- libexif/exif-data.c.old Fri Apr  1 15:36:02 2005
+++ libexif/exif-data.c Fri Apr  1 15:36:50 2005
@@ -475,7 +475,7 @@
 #endif
 
/* Byte order (offset 6, length 2) */
-   if (size < 12)
+   if (size < 14)
return;
if (!memcmp (d + 6, "II", 2))
data->priv->order = EXIF_BYTE_ORDER_INTEL;


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