date:20080120

Bug#461457: xorg: Doesn't honour DisplaySize

2008-01-20 Thread Kevin Locke

tags 461457 + upstream
thanks

It appears that this bug has already been reported upstream as bug
12474 https://bugs.freedesktop.org/show_bug.cgi?id=12474.
Apparently the DDC information is incorrectly taking precidence over
the DisplaySize configuration option.  See
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=48ca5961caee62f2980017a6bdc96a1b4c747727
for the patch.

Cheers,
Kevin



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

Bug#455731: Bug#461349: (upgrade stalls w/100% CPU ... ) / Merge with #455731?

2008-01-20 Thread A. Costa

I used 'dpkg' to downgrade from 'cupsys' v1.3.5-1 to v1.3.4-4, but the
downgrade produced the same bug, (100% CPU unkillable 'index++'
stall).  Which implies 'cupsys' is not the problem.

During an upgrade of a couple hundred packages the other night, the same
bug occurred with other packages, such as:

slib (3a5-3)
maint-guide (1.2.12)
gimp-help-en (2.4.0-2)

...and others.  It's hard to imagine how 'cupsys' could cause that.
Perhaps this bug's 'severity' should be worse than 'important'.  It
breaks 'apt-get' too, since after the error 'apt-get' fails and
suggests running 'dpkg --configure -a' which also fails.  (Plain 'dpkg'
still works.)

More online searching revealed this harmless-looking bug:

#455731 dhelp cron failed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455731

I tried the '/usr/lib/ruby/1.8/dhelp.rb' patch suggested there, (see
attached .diff), and it helped (in an odd way):

% dpkg -i cupsys_1.3.5-1_i386.deb
{ ...etc... }
Preparing to replace cupsys 1.3.4-4 (using .../cupsys_1.3.5-1_i386.deb) 
...
Stopping Common Unix Printing System: cupsd.
Unpacking replacement cupsys ...
Setting up cupsys (1.3.5-1) ...
Dhelp::IndexerError: Couldn't index /var/lib/doc-base/documents/cupsys 
using /usr/bin/index++ --config-file /usr/share/dhelp/swish++.conf --index-file 
/var/lib/dhelp/documents.index --incremental - 
(/usr/lib/ruby/1.8/dhelp.rb:368:in `index'
/usr/sbin/dhelp_parse:112:in `main'
/usr/lib/ruby/1.8/commandline/application.rb:250:in `run'
/usr/lib/ruby/1.8/commandline/application.rb:269:in `__set_auto_run'
/usr/sbin/dhelp_parse:93)
Starting Common Unix Printing System: cupsd.

...that is the patch is inapplicable, buggy, or maybe I typed it in
wrong, and it breaks '/usr/lib/ruby/1.8/dhelp.rb'; but that breakage
prevents the 100% CPU unkillable process.  After the patch 'dpkg
--configure -a' worked, which fixed 'apt-get'.  Some document index
aren't updated, but that's the lesser of two evils.

Bugs #46139  #455731 seem somehow related; should they be merged?  If not,
to what other package might this bug belong?

HTH...



--- /usr/lib/ruby/1.8/dhelp.rb	2007-12-06 12:06:00.0 -0500
+++ /tmp/1.8/dhelp.rb	2008-01-20 01:56:56.0 -0500
@@ -127,7 +127,7 @@
 end
 
 def files
-  @files.strip.split(/\s+/)
+  @files.to_s.strip.split(/\s+/)
 end
   end
 
@@ -384,6 +384,7 @@
   @pool.each do |doc|
 doc.formats.each do |format|
   next unless SUPPORTED_FORMATS.include? format.format.downcase
+	  puts processing files for #{doc.document}'s format #{format.format}
   format.files.each do |glob|
 # Dirnames can be globs too. There will also be duplicates
 # (different formats, same doc), hence the set

Bug#461665: FTBFS with GCC 4.3: missing #includes

2008-01-20 Thread Martin Michlmayr

Package: vbrfix
Version: 0.24-1
Usertags: ftbfs-gcc-4.3

Your package fails to build with GCC 4.3.  Version 4.3 has not been
released yet but I'm building with a snapshot in order to find errors
and give people an advance warning.  In GCC 4.3, the C++ header
dependencies have been cleaned up.  The advantage of this is that
programs will compile faster.  The downside is that you actually
need to directly #include everything you use (but you really should
do this anyway, otherwise your program won't work with any compiler
other than GCC).  There's some more information about this at
http://gcc.gnu.org/gcc-4.3/porting_to.html

You can reproduce this problem with gcc-4.3 or gcc-snapshot from
unstable.

 Automatic build of vbrfix_0.24-1 on em64t by sbuild/amd64 0.53
...
 make[4]: Entering directory `/build/tbm/vbrfix-0.24/vbrfixc'
 source='vbrfix.cpp' object='vbrfix.o' libtool=no \
   depfile='.deps/vbrfix.Po' tmpdepfile='.deps/vbrfix.TPo' \
   depmode=gcc3 /bin/sh ../admin/depcomp \
   x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. 
 -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -pedantic -W -Wpointer-arith 
 -Wmissing-prototypes -Wwrite-strings -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE 
 -Wcast-align -Wconversion -O2 -fno-exceptions -fno-check-new -fexceptions  -c 
 -o vbrfix.o `test -f vbrfix.cpp || echo './'`vbrfix.cpp
 cc1plus: warning: command line option -Wmissing-prototypes is valid for 
 Ada/C/ObjC but not for C++
 In file included from vbrfix.h:22,
  from vbrfix.cpp:17:
 wputil.h: In member function 'int wps::length()':
 wputil.h:87: warning: conversion to 'int' from 'size_t' may alter its value
 wputil.h: In static member function 'static wps wfile::loadSetting(const 
 char*, wps, wps)':
 wputil.h:211: warning: conversion to 'int' from 'size_t' may alter its value
 wputil.h:217: warning: conversion to 'unsigned int' from 'long unsigned int' 
 may alter its value
 wputil.h: In static member function 'static void wfile::saveSetting(const 
 char*, wps, wps)':
 wputil.h:241: warning: conversion to 'int' from 'size_t' may alter its value
 In file included from vbrfix.cpp:17:
 vbrfix.h: In member function 'int VbrFix::getPercent()':
 vbrfix.h:45: warning: conversion to 'int' from 'long unsigned int' may alter 
 its value
 vbrfix.cpp: In member function 'void VbrFix::startWriting()':
 vbrfix.cpp:51: warning: conversion to 'int' from 'long int' may alter its 
 value
 vbrfix.cpp:51: warning: conversion to 'int' from 'long unsigned int' may 
 alter its value
 vbrfix.cpp: In member function 'bool VbrFix::startFix(const char*, const 
 char*)':
 vbrfix.cpp:64: warning: conversion to 'int' from 'long unsigned int' may 
 alter its value
 vbrfix.cpp:65: error: 'strcmp' was not declared in this scope
^^

-- 
Martin Michlmayr
http://www.cyrius.com/



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

Bug#461666: FTBFS with GCC 4.3: missing #includes

2008-01-20 Thread Martin Michlmayr

Package: codeine
Version: 1.0.1-3.dfsg-2
Usertags: ftbfs-gcc-4.3

Your package fails to build with GCC 4.3.  Version 4.3 has not been
released yet but I'm building with a snapshot in order to find errors
and give people an advance warning.  In GCC 4.3, the C++ header
dependencies have been cleaned up.  The advantage of this is that
programs will compile faster.  The downside is that you actually
need to directly #include everything you use (but you really should
do this anyway, otherwise your program won't work with any compiler
other than GCC).  There's some more information about this at
http://gcc.gnu.org/gcc-4.3/porting_to.html

You can reproduce this problem with gcc-4.3 or gcc-snapshot from
unstable.

 Automatic build of codeine_1.0.1-3.dfsg-2 on em64t by sbuild/amd64 0.53
...
 g++ -o build/app/xineEngine.o -c -I/usr/include/kde/ -I/usr/include/qt3 -O2 
 -DNDEBUG -DNO_DEBUG -DQT_NO_TRANSLATION -Ibuild/app -Isrc/app -Ibuild -Isrc 
 -I. src/app/xineEngine.cpp
 src/app/xineEngine.cpp: In member function 'QString 
 Codeine::VideoWindow::fileFilter() const':
 src/app/xineEngine.cpp:871: error: 'free' is not a member of 'std'
 scons: *** [build/app/xineEngine.o] Error 1
 scons: building terminated because of errors.
 make: *** [common-build-impl] Error 2
 dpkg-buildpackage: failure: debian/rules build gave error exit status 2

-- 
Martin Michlmayr
http://www.cyrius.com/



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

Bug#461355: tomcat5.5: More restrictive JULI permissions break java.util.logging.

2008-01-20 Thread Michael Koch

On Sat, Jan 19, 2008 at 11:46:47PM -0800, Alexander Hvostov wrote:
On Saturday 19 January 2008, Marcus Better wrote:
If the user creates that file then the security exception still gets
thrown, so it would be very confusing to pretend the file doesn't
exist. I'm not too happy about this idea.

In that case, we would need to grant FilePermission to read the
logging.properties file in the appropriate place in each Web application
directory.

To do this automatically, Tomcat would most likely have to provide a
custom java.security.Policy implementation that, in addition to granting
permissions defined by the configured security policy, also grants read
access to each webapp's own logging.properties file.

Upstream has this in catalina.properties (in SVN, not yet released).

// To enable per context logging configuration, permit read access to
the appropriate file.
// Be sure that the logging configuration is secure before enabling
such access
// eg for the examples web application:
// permission java.io.FilePermission
${catalina.base}${file.separator}webapps${file.separator}examples${file.separator}WEB-INF${file.separator}classes${file.separator}logging.properties,
read;

I'm afraid this is a far bigger project than I'm willing to take on, but
perhaps someone among the Apache folks will do it, so why not forward
this bug upstream?

1 2 3 4 5 >

1 - 100 of 469 matches

Mail list logo