Bug#353263: ITP: freealut -- OpenAL Utility Toolkit
Package: wnpp Owner: Debian Games Team <[EMAIL PROTECTED]> Severity: wishlist I intend to package freealut for the Debian Games Team. freealut was previously distributed with OpenAL, but has been split from the main release, so it is necessary to provide freealut in order to package the new version of OpenAL. * Package name: freealut Version : 1.0.1 Upstream Author : Steve Baker, Sven Panne, Erik Hofman and Prakash Punnoor * URL : http://www.openal.org * License : LGPL-2 Description : OpenAL Utility Toolkit freealut is a free implementation of OpenAL's ALUT standard. ALUT is a set of portable functions which remove the annoying details of getting an audio application started. It is the OpenAL counterpart of what GLUT is for OpenGL. Thierry signature.asc Description: Digital signature
Bug#342466: ITP: rcairo -- Cairo bindings for the Ruby language
Package: wnpp Owner: Thierry Reding <[EMAIL PROTECTED]> Severity: wishlist * Package name: rcairo Version : 1.0.0 Upstream Author : Evan Marin, Øyvind Kolås, MenTaLguY, Kouhei Sutou * URL : http://cairographics.org/rcairo * License : GPL Description : Cairo bindings for the Ruby language Cairo is a multi-platform library providing anti-aliased vector-based rendering for multiple target backends. This package contains libraries for using Cairo with the Ruby programming language. It is most likely useful in conjunction with Ruby bindings for other libraries such as GTK+. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-fglrx-alsa Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) signature.asc Description: Digital signature
Bug#345616: svn-buildpackage: patch implementing --no-branches
* Eduard Bloch wrote: > #include > * Thierry Reding [Mon, Jan 02 2006, 06:48:59PM]: > > > > > The patch is relatively small, but may need some cleaning up. > > > > > > Yeah. > > > > > > *hint* It would be really handy to see what it is actually supposed > > > to do by reading something in the manual or at least in a manpage, but > > > you did not add any docs. > > > > I should of course have done that, do you want me to prepare another patch? > > Yes, please ;) > Here goes. If you need me to provide something more, or if you think the documentation could be more elaborate, please let me know. Thierry P.S.: sorry Eduard for not sending this mail to the BTS the first time diff -Nur svn-buildpackage-0.6.14.orig/doc/HOWTO.sgml svn-buildpackage-0.6.14/doc/HOWTO.sgml --- svn-buildpackage-0.6.14.orig/doc/HOWTO.sgml 2005-09-23 16:17:33.0 +0200 +++ svn-buildpackage-0.6.14/doc/HOWTO.sgml 2006-01-02 19:15:05.0 +0100 @@ -442,6 +442,11 @@ If you actually decide to stop using the mergeWithUpstream-mode, unset the mergeWithUpstream property as follows: svn propdel mergeWithUpstream debian/. + +If you don't want to store the upstream sources of all your packages in the +repository, you can pass the --no-branches switch to +svn-inject, which will prevent svn-inject from creating a +branches subdirectory.
Bug#349555: komi - FTBFS: cannot find -lgp
* Bastian Blank wrote: > Package: komi > Version: 1.03-4 > Severity: serious > > There was an error while trying to autobuild your package: > > > Automatic build of komi_1.03-4 on debian01 by sbuild/s390 85 > [...] > > cc -Wall -pedantic -std=c99 -O2 -I/usr/include/SDL -D_REENTRANT > > -DDATAPATH=\"/usr/share/games/komi/\" komi.o -o komi -L/usr/lib -lSDL > > -lpthread -lm -ldl -L/usr/lib -lasound -lm -ldl -lpthread -L/usr/lib -ldl > > -lartsc -lpthread -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 -L/usr/lib > > -lesd -laudiofile -lm -laudio -lXt -L/usr/X11R6/lib -lX11 -lXext -laa -lgpm > > -L/usr/lib -laa -lm -L/usr/X11R6/lib -lX11 -lslang -lncurses -lSDL_mixer > > /usr/bin/ld: cannot find -lgpm > > collect2: ld returned 1 exit status > > make[1]: *** [komi] Error 1 > > make[1]: Leaving directory `/build/buildd/komi-1.03' > > make: *** [build-stamp] Error 2 > > ** > > Build finished at 20060123-1242 > > FAILED [dpkg-buildpackage died] I've investigated this a bit, and it looks like the upstream Makefile links statically against SDL. I've tried rebuilding with dynamic linking and it solves the FTBFS. Any reason why komi would link statically against SDL? Steve? If not, maybe the attached patch should be applied. Thierry Index: Makefile === --- Makefile(revision 41) +++ Makefile(working copy) @@ -11,7 +11,7 @@ MANPATH=/usr/local/man/man6/ MIXER=-lSDL_mixer -SDL_LIB=$(shell sdl-config --static-libs) $(MIXER) +SDL_LIB=$(shell sdl-config --libs) $(MIXER) CFLAGS=-Wall -pedantic -std=c99 -O2 \ $(shell sdl-config --cflags) \ signature.asc Description: Digital signature
Bug#273018: Missing dependency on libgpmg1-dev
The NMU that was supposed to fix this bug only did so partially. While sdl-config now lists -lgpm for the --static-libs option, the libsdl1.2-dev package is still missing a dependency on libgpmg1-dev as mentioned by Daniel Burrows in the original bug report. Thierry signature.asc Description: Digital signature
Bug#273018: Fixed in NMU of libsdl1.2 1.2.9-0.0
* Sam Hocevar wrote: > tag 171617 + fixed > tag 246477 + fixed > tag 273018 + fixed > tag 319261 + fixed > tag 335689 + fixed > tag 337668 + fixed > > quit > > This message was generated automatically in response to a > non-maintainer upload. The .changes file follows. > [...] I do not believe that this bug was completely fixed in that NMU. While sdl-config now lists `-lgpm' for the --static-libs option, the libsdl1.2-dev package is still missing a build-dependency on libgpmg1-dev as mentioned by Daniel Burrows in the original bug report. Thierry signature.asc Description: Digital signature
Bug#349799: Adoption by the Debian/Ruby Extras Team
retitle 349799 ITA: liblog4r-ruby -- A logging library for Ruby owner 349799 [EMAIL PROTECTED] thanks signature.asc Description: Digital signature
Bug#273018: Fixed in NMU of libsdl1.2 1.2.9-0.0
* Sam Hocevar wrote: > tag 171617 + fixed > tag 246477 + fixed > tag 273018 + fixed > tag 319261 + fixed > tag 335689 + fixed > tag 337668 + fixed > > quit > > This message was generated automatically in response to a > non-maintainer upload. The .changes file follows. > [...] I do not believe that this bug was completely fixed in that NMU. While sdl-config now lists `-lgpm' for the --static-libs option, the libsdl1.2-dev package is still missing a build-dependency on libgpmg1-dev as mentioned by Daniel Burrows in the original bug report. Thierry signature.asc Description: Digital signature
Bug#273018: Build-Depends on libgpmg1-dev still missing
The last NMU fixed only part of the problem. While sdl-config now lists -lgpm with the --static-libs option, the libsdl1.2-dev package is still missing a build-dependency on libgpmg1-dev as mentioned by Daniel Burrows in the original bug report. Thierry signature.asc Description: Digital signature
Bug#273018: Build-Depends on libgpmg1-dev still missing
The last NMU fixed only part of the problem. While sdl-config now lists -lgpm with the --static-libs option, the libsdl1.2-dev package is still missing a build-dependency on libgpmg1-dev as mentioned by Daniel Burrows in the original bug report. Thierry signature.asc Description: Digital signature
Bug#273018: flooding...
Sorry for flooding the BTS, it seems as though all the emails I tried to send did actually go out, even though my MTA said they didn't =\ Thierry signature.asc Description: Digital signature
Bug#351270: ITP: libgpgme-ruby -- GPGME bindings for the Ruby language
Package: wnpp Severity: wishlist * Package name: libgpgme-ruby Version : 0.2 Upstream Author : Daiki Ueno * URL : http://deisui.org/~ueno/ruby/ruby-gpgme/ * License : GPL Description : GPGME bindings for the Ruby language GnuPG Made Easy (GPGME) is a library designed to make access to GnuPG easier for applications. It provides a High-Level Crypto API for encryption, decryption, signing, signature verification and key management. This package contains libraries for using GPGME with the Ruby programming language. I intend to package libgpgme-ruby and team maintain it as part of the Debian/Ruby Extras team. Thierry signature.asc Description: Digital signature
Bug#345616: svn-buildpackage: patch implementing --no-branches
Package: svn-buildpackage
Version: 0.6.14
Severity: wishlist
Tags: patch
Hi,
after some discussion on IRC about the usefulness of a --no-branches option, I
implemented this patch, which adds the --no-branches option to svn-inject.
The original idea came up in the pkg-ruby-extras project, which uses a build
system that pulls in upstream sources using a different script. The `branches'
subdirectory is not needed in their repository layout.
The patch is relatively small, but may need some cleaning up.
Cheers,
Thierry
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-fglrx-alsa
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Versions of packages svn-buildpackage depends on:
ii devscripts 2.9.10 Scripts to make the life of a Debi
ii libsvn-core-perl1.2.3dfsg1-3 perl bindings for Subversion (aka.
ii perl5.8.7-10 Larry Wall's Practical Extraction
ii subversion 1.2.3dfsg1-3 advanced version control system (a
ii subversion-tools1.2.3dfsg1-3 assorted tools related to Subversi
svn-buildpackage recommends no packages.
-- no debconf information
diff -Nur svn-buildpackage-0.6.14.orig/svn-inject
svn-buildpackage-0.6.14/svn-inject
--- svn-buildpackage-0.6.14.orig/svn-inject 2005-10-13 21:29:24.0
+0200
+++ svn-buildpackage-0.6.14/svn-inject 2006-01-02 01:50:36.0 +0100
@@ -49,6 +49,7 @@
my $opt_dolike;
my $opt_addtar;
#my $opt_trackmode;
+my $opt_no_branches;
# parse Command line
%options = (
@@ -61,7 +62,8 @@
"o" => \$opt_onlychanged,
# "u=s" => \$opt_trackmode,
"add-tar" => \$opt_addtar,
- "c=i" => \$opt_checkout
+ "c=i" => \$opt_checkout,
+ "no-branches" => \$opt_no_branches
);
&help unless ( GetOptions(%options));
@@ -173,7 +175,7 @@
chdir $tempdir;
# preparing a package tree that will be inserted into repository later
-if($dscOrig) {
+if($dscOrig && !$opt_no_branches) {
# prepare the upstream source
withecho "mkdir", "-p", "$package/branches/upstream";
chdir "$package/branches/upstream";
@@ -227,20 +229,25 @@
# Final tree prepation before commit, preconfiguring already
mkdir "$package/tags";
$SDCommon::c{"tagsUrl"}="$opt_svnurl/$package/tags";
-$SDCommon::c{"upsCurrentUrl"}="$opt_svnurl/$package/branches/upstream/current";
-$SDCommon::c{"upsTagUrl"}="$opt_svnurl/$package/branches/upstream";
+
+if (!$opt_no_branches) {
+
$SDCommon::c{"upsCurrentUrl"}="$opt_svnurl/$package/branches/upstream/current";
+ $SDCommon::c{"upsTagUrl"}="$opt_svnurl/$package/branches/upstream";
+}
# go, go, go
withecho "svn $SVN_QUIET import -m\"$scriptname Installing original source of
$package\" $package $opt_svnurl/$package";
# for non-native: create the trunk copy from the source and modify it
if($dscOrig) {
- withecho("svn", "-m", "$scriptname Tagging upstream source version of
$package", "copy",
- "$opt_svnurl/$package/branches/upstream/current",
- "$opt_svnurl/$package/branches/upstream/$upsVersion", $SVN_QUIET);
- withecho("svn", "-m", "$scriptname Forking $package source to Trunk",
"copy",
- "$opt_svnurl/$package/branches/upstream/current",
- "$opt_svnurl/$package/trunk", $SVN_QUIET);
+ if (!$opt_no_branches) {
+ withecho("svn", "-m", "$scriptname Tagging upstream source version of
$package", "copy",
+ "$opt_svnurl/$package/branches/upstream/current",
+ "$opt_svnurl/$package/branches/upstream/$upsVersion", $SVN_QUIET);
+ withecho("svn", "-m", "$scriptname Forking $package source to Trunk",
"copy",
+ "$opt_svnurl/$package/branches/upstream/current",
+ "$opt_svnurl/$package/trunk", $SVN_QUIET);
+ }
mkdir "tmp";
chdir "tmp";
withecho "dpkg-source -x $opt_dsc";
signature.asc
Description: Digital signature
Bug#345616: svn-buildpackage: patch implementing --no-branches
* Eduard Bloch wrote: > #include > * Thierry Reding [Mon, Jan 02 2006, 09:53:22AM]: > > Package: svn-buildpackage > > Version: 0.6.14 > > Severity: wishlist > > Tags: patch > > > > Hi, > > > > after some discussion on IRC about the usefulness of a --no-branches > > option, I > > implemented this patch, which adds the --no-branches option to svn-inject. > > > > The original idea came up in the pkg-ruby-extras project, which uses a build > > system that pulls in upstream sources using a different script. The > > `branches' > > subdirectory is not needed in their repository layout. > > > > The patch is relatively small, but may need some cleaning up. > > Yeah. > > *hint* It would be really handy to see what it is actually supposed > to do by reading something in the manual or at least in a manpage, but > you did not add any docs. I should of course have done that, do you want me to prepare another patch? Thierry > Eduard. signature.asc Description: Digital signature
Bug#323028: fetchmail: manpage typos
Package: fetchmail Version: 6.2.5-18 Severity: minor Tags: patch While browsing the fetchmail manpage, I found two typos in the section about the --tracepolls command-line option. A diff against the source package's manpage is included. Cheers, Thierry diff -Nur fetchmail-6.2.5.orig/fetchmail.man fetchmail-6.2.5/fetchmail.man --- fetchmail-6.2.5.orig/fetchmail.man 2005-08-14 10:38:26.0 +0200 +++ fetchmail-6.2.5/fetchmail.man 2005-08-14 10:39:36.0 +0200 @@ -273,11 +273,11 @@ .TP .B \-\-tracepolls (Keyword: tracepolls) -Tell fetchail to poll trace information in the form `polling %s +Tell fetchmail to poll trace information in the form `polling %s account %s' to the Received line it generates, where the %s parts are replaced by the user's remote name and the poll label (the Received header also normally includes the server's truename). This can be -used to facilate mail filtering based on the account it is being +used to facilitate mail filtering based on the account it is being received from. .TP .B \-\-ssl signature.asc Description: Digital signature
Bug#236582: I intend to adopt billard-gl
retitle 236582 ITA: billard-gl -- OpenGL billiards game owner 236582 ! thanks Hello, I intend to adopt the billard-gl package. I've been doing some work on fixing outstanding bugs. So far I have patches that should solve #173197 (more of a workaround which I cannot test since I don't use Xinerama myself), #248201, #284855 and #290822 (the fix for this one was provided in the bug report). I've also contacted upstream since they've apparently resumed work on the software. I haven't gotten an answer yet though, but I'll keep bugging them. Regards, Thierry signature.asc Description: Digital signature
Bug#284855: Fix: start in windowed mode at 640x480 window size
tags 284855 + patch thanks Hello, the attached fix will make the game start in windowed mode by default. This should get rid of the problem that you describe. Changing the window size from 800x600 to 640x480 was done to also prevent problems on 800x600 displays. I'm in the process of adopting the billard-gl package, and provided everything goes right, this fix will be included in the next release. Thierry diff -Nur billard-gl-1.75.orig/src/KommandoZeilenParameter.cpp billard-gl-1.75/src/KommandoZeilenParameter.cpp --- billard-gl-1.75.orig/src/KommandoZeilenParameter.cpp2002-04-23 18:04:13.0 +0200 +++ billard-gl-1.75/src/KommandoZeilenParameter.cpp 2005-01-22 12:42:31.0 +0100 @@ -144,7 +144,7 @@ BandenFaktor = 0.4; KollisionsFaktor = 0.95; ZBufferLoeschen = 1; - BildschirmAufloesung = 800; + BildschirmAufloesung = 640; Farbtiefe= 16; Reflektionen = 0; Sprache = 0; @@ -154,7 +154,7 @@ TischLampen = 2; GrueneLampe = 0; - FullScreen = 1; + FullScreen = 0; EffektLautstaerke= .5; MusikLautstaerke = .5; signature.asc Description: Digital signature
Bug#173197: Workaround
Hello, I just posted a fix to bug #284855[1] which should also workaround the problem that you describe. Thierry [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284855 signature.asc Description: Digital signature
Bug#284855: Command-line option
Hi, I forgot to mention this earlier: there is also an undocumented command-line option to explicitly switch to windowed mode (-w or -windowed) aswell as fullscreen (-f or -fullscreen). I still believe the default should be windowed mode though. Thierry signature.asc Description: Digital signature
Bug#291738: Fix
tags 291738 + patch thanks The attached patch adds `Request for Sponsor' as definition for the acronym RFS. Thierry --- vera-1.12.orig/vera.r +++ vera-1.12/vera.r @@ -489,6 +489,9 @@ @item RFS REXX File System (REXX, CICS, VSAM, IBM) [EMAIL PROTECTED] RFS +Request for Sponsor (Linux, Debian) + @item RFT Request For Technology (OSF) signature.asc Description: Digital signature
Bug#295289: billard-gl: impossible to hit ball at full strength
* Jacek Politowski wrote:
[...]
> On my current hardware I can't hit ball at full strength.
> (not exactly true, but you'll find out later)
>
> It always gets hit at about 8-10% of full strength, always the same
> value, after the same time.
>
> After some testing I managed to find out it's the matter of autorepeat
> times of keyboard.
> When I turn off autorepeat ('xset r off') BillardGL works fine (but the
> rest of my system doesn't - autorepeat is quite useful and nice feature)
> So, this bug renders BillardGL practically useless to me.
Hi Jacek!
Thanks for the bug report. What you are describing in indeed a known problem.
The problem is not with billard-gl however, but due to glutIgnoreKeyRepeat()
being broken in freeglut3 2.2.0. You can find further information in the bug
reports for #248201[1] and #293687[2] (with a couple of workarounds).
> This bug is reported to upstream author,
> http://www.ameds.de/billardgl/read.php?f=4&i=1&t=1
> but BillardGL seems practically dead upstream, so forwarding bug
> to Tobias Nopper probably won't solve the problem.
Upstream was practically inactive until fairly recently. They are currently
planning a complete rewrite of billard-gl and are considering using SDL.
> I tried to sort things out myself, but plenty of BillardGL code is
> written/documented in German (eg. variable names).
> So, unfortunately, I had to give up trying to analyze program to make
> useful patch.
I recommend you try the workarounds that I have proposed in [2].
> Anyway. It seems that BillardGL tries to read key events at level way
> too low, which leads to trouble on certain, specific hardware.
billard-gl's handling of key events is not at fault here. It is freeglut3
that is broken in this regard.
Hope this helps.
Cheers,
Thierry
[1]: http://bugs.debian.org/248201
[2]: http://bugs.debian.org/293687
signature.asc
Description: Digital signature
Bug#296605: default configure option --with-exempt=sudo
Package: sudo Version: 1.6.8p5-1 Severity: normal sudo is configured with '--with-exempt=sudo' by default. This results in behaviour that is not documented in the manpage (only in /usr/share/doc/sudo/OPTIONS). Everyone in the sudo group can run sudo without entering a password. Using the PASSWD option for the sudo group in /etc/sudoers doesn't change this behaviour. Wouldn't it be more obvious to put "%sudo ALL=NOPASSWD: ALL" into /etc/sudoers instead, in order to achieve the same default behaviour (if really desired and/or needed). Perhaps make it a default entry in /etc/sudoers, or a commented example entry? Cheers, Thierry signature.asc Description: Digital signature
Bug#288158: Fix
Hi,
After thorough discussion, and a lot of help from people in #debian-women
(mainly Jeroen van Wolffelaar, Steve Langasek, Branden Robinson and Helen
Faulkner) I was able to finish this patch.
The patch adapts parts of the cleanlinks script which I was pointed to by
Steve. cleanlinks is part of the xutils package. The adapted script
replaces the calls to symlinks in /etc/cron.daily/lists-archive. Thus it
removes the dependency on the symlinks package, as requested by Frank
Lichtenstein in the original bug report.
Initially, a simpler script was tested, which turned out to be vulnerable to
maliciously constructed symlinks. This is solved in the new script by the use
of the -f test since, as Steve mentioned, "the only time [ -f "$i" ] returns
false for something that's on the filesystem is a dangling symlink".
The attached patch contains all the changes, including those to the copyright
file as discussed with Branden on IRC as well as the removed dependency on
the symlinks package.
Thanks again to Jeroen, Steve, Branden and Helen; I couldn't have done this
without their help.
--Thierry
diff -Nur lists-archives-200300506.orig/debian/control
lists-archives-200300506/debian/control
--- lists-archives-200300506.orig/debian/control2003-05-07
21:01:53.0 +0200
+++ lists-archives-200300506/debian/control 2005-01-10 00:34:13.0
+0100
@@ -7,7 +7,7 @@
Package: lists-archives
Architecture: all
-Depends: perl5, mhonarc, procmail, symlinks
+Depends: perl5, mhonarc, procmail
Description: Web archive for mailing lists
Creates a website of historical posts to mailing lists, in the sorted
style used by the Debian Project (http://www.debian.org/Lists-Archives).
diff -Nur lists-archives-200300506.orig/debian/copyright
lists-archives-200300506/debian/copyright
--- lists-archives-200300506.orig/debian/copyright 2001-08-27
16:03:57.0 +0200
+++ lists-archives-200300506/debian/copyright 2005-01-12 01:36:25.0
+0100
@@ -16,3 +16,41 @@
On Debian GNU/Linux systems, the text of the GPL can be found in
/usr/share/common-licenses/GPL.
+
+
+The script /etc/cron.daily/lists-archives includes code adapted from the
+`cleanlinks' script that is copyright (C) 2000 by The XFree86 Project, Inc.
+and released under the XFree86 1.0 License, the text of which follows:
+
+---
+
+XFree86 License
+
+XFree86 code without an explicit copyright is covered by the following copy-
+right/license:
+
+Copyright (C) 1994-2003 The XFree86 Project, Inc. All Rights Reserved.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is fur-
+nished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FIT-
+NESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
+IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CON-
+NECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+Except as contained in this notice, the name of the XFree86 Project shall not
+be used in advertising or otherwise to promote the sale, use or other deal-
+ings in this Software without prior written authorization from the XFree86
+Project.
+
+---
diff -Nur lists-archives-200300506.orig/debian/cron.daily
lists-archives-200300506/debian/cron.daily
--- lists-archives-200300506.orig/debian/cron.daily 2003-05-06
18:13:47.0 +0200
+++ lists-archives-200300506/debian/cron.daily 2005-01-12 01:48:31.0
+0100
@@ -1,4 +1,25 @@
#!/bin/sh -e
+
+# Silently remove dangling symlinks.
+#
+# This function is adapted from the `cleanlinks' program which is part of
+# XFree86 (see /usr/share/doc/lists-archives/copyright).
+function clean_symlinks
+{
+if [ -n "$1" ]; then
+find "$1" -type l -print |
+(
+read i || break
+while [ -n "$i" ]; do
+if [ ! -f "$i" ]; then
+rm -f "$i"
+fi
+read i || break
+done
+)
+fi
+}
+
[ -d /var/lib/lists-archives/archives ] || exit 0
umask 002
@@ -23,8 +44,7 @@
[ -f ../lists/$dir ] || touch ../lists/$dir
done
-# Not sure yet why this is needed. :-)
-symlinks -dr /var/lib/lists-archives > /dev/null 2>&1
+clean_symlinks /var/lib/lists-archives
# Fix stray ownerships and permissions (searchlist
Bug#293687: billard-gl: keyrepeat makes shooting impossible
merge 293687 248201 thanks * Jeff King ([EMAIL PROTECTED]) wrote: > Package: billard-gl > Version: 1.75-7 > Severity: minor > > I was having trouble holding down the spacebar to shoot. The power meter > would only go up about 1/10 of the way before shooting (even though I > was still holding the spacebar). The resulting shot was quite weak, > making the game unplayable. > > To solve this, I turned off keyrepeat for my X display (by writing a C > program which calls XAutoRepeatOff()). Billard-gl should either: > - call XAutoRepeatOff() itself (and turn it back on when it's done) > - work with auto repeat on > The second is obviously preferable, since the setting affects all > windows. > Hello Jeff, Thanks for the bug report! However, this bug has already been reported once (#248201), and turns out to be related to glutIgnoreKeyRepeat() being broken in freeglut3 2.2.0. That bug has been fixed in freeglut upstream CVS, but the Debian package (which is not based on the upstream CVS version) does not incorporate these changes. There are currently three workarounds for this: a) do as you did, disable autorepeat for that display, b) use the patches attached to #248201 and build a custom freeglut3 (I have tested this, and works as expected), or c) you use the middle mouse button, which performs the same function as the spacebar. I hope this helps you. For the elegant fix, we'll probably have to wait for the next release of freeglut3. I will merge this bug with #248201. Cheers, Thierry signature.asc Description: Digital signature
Bug#407055: compiz: manages only screen 0 of a multi screen display
* Mikko Tuumanen wrote: > Package: compiz > Version: 0.2.2-1 > Severity: normal > > When using a dualhead setup with two screens (:0.0 and :0.1) > compiz works only on the :0.0 and makes the :0.1 totally > unusable. > > I can start programs on the other screen (and verify they are there > with xlsclients), but they can't be seen or used. > > Trying to manage the other screen with some other window manager > when compiz is running doesn't help. Version 0.2.2 has no (working) support for multihead setups. compiz 0.3.6, which should be uploaded to experimental sometime soon should fix that. Thierry signature.asc Description: Digital signature
Bug#376812: I have a Voodoo2 card...
* Wouter Verhelst wrote: > Hi, > > I have such a card, but it's sitting in a machine that runs Sarge (and > I'm not going to update it to etch before that's released). > > If it would help, I'd be willing to run some tests on that box. Just > tell me what you want me to do and what information you need back, and > I'll do so. I've been asked to look at this bug as part of my T&S for the NM process. Wouter, could you try rebuilding glide with -fno-strict-aliasing? I have attached a diff that patches debian/rules to add that to CFLAGS. This is mainly just guessing but the same solution did fix a similar bug in mesa recently. If that doesn't work, perhaps you could try to get a backtrace of running one of the segfaulting binaries against a non-stripped glide library (i.e. rebuild with something like "DEB_BUILD_OPTIONS=nostrip debuild"). Thierry signature.asc Description: Digital signature
Bug#376812: I have a Voodoo2 card...
* Thierry Reding wrote: [...] > could you try rebuilding glide with -fno-strict-aliasing? I have attached a > diff that patches debian/rules to add that to CFLAGS. This is mainly just > guessing but the same solution did fix a similar bug in mesa recently. [...] And here's the missing patch, sorry. Thierry Index: debian/rules === --- debian/rules (revision 95) +++ debian/rules (working copy) @@ -29,7 +29,7 @@ DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) -CFLAGS = -g -Wall +CFLAGS = -g -Wall -fno-strict-aliasing ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 signature.asc Description: Digital signature
Bug#400894: FTBFS: tries to write in $HOME
tag 400894 + patch
thanks
* Lex Spoon wrote:
> The problem is related to bug 397045. The package depends on
> "ant" and on "gcj" in order to try and get a setup for compiling
> Java code using ant. I am not sure what the dependencies should
> be changed to.
>
> I will leave it alone for now, in the hopes that the ant and/or gcj
> maintainers make this combination of dependencies sufficient
I have been looking at this bug as part of T&S (New Maintainer process) and
have attached a patch that should fix the build failure.
The change that fixes the primary build-failure is to set scala.home in
build.xml to /usr/share and scala.lib.dir to ${scala.home}/java.
Alternatively scala.lib.dir could be set to /usr/share/java directly. That
enables the build to correctly find the scala-{compiler,library}.jar files.
However, building in clean sid chroot also revealed some subsequent build
failures: libservlet2.3-java doesn't provide the servlet-api.jar, only
libservlet2.4-java does. In order to generate the PDF documentation, sbaz
needs build-dependencies on tetex-bin | texdoctk (for pdflatex) and
tetex-extra for (times.sty).
Using the NMU diff below makes sbaz build fine in a clean sid chroot.
Cheers,
Thierry
diff -u sbaz-1.18/debian/changelog sbaz-1.18/debian/changelog
--- sbaz-1.18/debian/changelog
+++ sbaz-1.18/debian/changelog
@@ -1,3 +1,19 @@
+sbaz (1.18-1.1) unstable; urgency=high
+
+ * Non-maintainer upload: (Closes: #400894)
++ Add build-dependency on java-gcj-compat-dev.
++ Set scala.home in build.xml to /usr/share and scala.lib.dir to
+ ${scala.home}/java, which is where scala and scala-library install the
+ required JAR files.
++ Build-depend on libservlet2.4-java instead of libservlet2.3-java.
++ Add build-dependency on tetex-bin | texdoctk which provide pdflatex
+ needed to build PDF documentation.
++ Build-depend on tetex-extra which provides fonts needed to build the PDF
+ documentation.
+ * Urgency set to high because it fixes an RC bug.
+
+ -- Thierry Reding <[EMAIL PROTECTED]> Fri, 19 Jan 2007 09:58:40 +0100
+
sbaz (1.18-1) unstable; urgency=low
* New upstream release.
diff -u sbaz-1.18/build.xml sbaz-1.18/build.xml
--- sbaz-1.18/build.xml
+++ sbaz-1.18/build.xml
@@ -2,9 +2,9 @@
-
+
-
+
only in patch2:
unchanged:
--- sbaz-1.18.orig/debian/control
+++ sbaz-1.18/debian/control
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Lex Spoon <[EMAIL PROTECTED]>
Standards-Version: 3.7.2
-Build-Depends: scala, ant, libservlet2.3-java, junit, debhelper (>= 5)
+Build-Depends: scala, ant, libservlet2.4-java, junit, debhelper (>= 5), java-gcj-compat-dev, tetex-bin | texdoctk, tetex-extra
Package: sbaz
Architecture: all
signature.asc
Description: Digital signature
Bug#400894: FTBFS: tries to write in $HOME
* Frank Küster wrote: > Hi Thierry, > > thank you for the patch. I have some critical remarks, though, with my > TeX maintainer hat on: > > Thierry Reding <[EMAIL PROTECTED]> wrote: > > > However, building in clean sid chroot also revealed some subsequent build > > failures: libservlet2.3-java doesn't provide the servlet-api.jar, only > > libservlet2.4-java does. In order to generate the PDF documentation, sbaz > > needs build-dependencies on tetex-bin | texdoctk (for pdflatex) and > > tetex-extra for (times.sty). > > - texdoctk does not exist at all (it once existed pre-potato), and it > never provided pdflatex. It still exists as an executable in > tetex-bin and texlive-base-bin, but it is a Perl-TK interface to TeX > documentation I will drop that alternative then, and make it explicit. Thanks for explaining. > - tetex will be dropped in lenny, all dependencies in etch should have > an alternative on the respective texlive packages. For sbaz, this > probably means > > tetex-bin | texlive-latex-base, tetex-extra | texlive-fonts-recommended > > but actually there's no simple rule for tetex->texlive mappings. You > have to try, maybe it needs more packages. If it builds documentation > in other languages than english, it needs the respective > texlive-lang-* package. I guess in that case it'd be okay to make texlive-latex-base and texlive-fonts-recommended the default alternatives instead of the tetex equivalents? > - finally (but this has nothing to do with Debian packaging): times.sty > is obsolete (since about 10 years), mathptmx.sty should be used > instead. Yeah, that is probably something to be taken up with upstream. > Regards, Frank Thanks for your comments Frank. Cheers, Thierry signature.asc Description: Digital signature
Bug#394311: Me too
* Alan Chandler wrote: > When is the patch in this bug report going to be applied? I too have a > Motherboard with the i965G chip on, and can't display any 3D stuff as a > result of it. You could try the experimental branch of the XSF git repository of mesa, like so: $ git-clone http://git.debian.org/git/pkg-xorg/lib/mesa.git $ git-checkout experimental $ debuild I don't think this will make it into etch though. Cheers, Thierry signature.asc Description: Digital signature
Bug#401943: Compiz crash problem solved.
* Fred VIDIL wrote: > Ok, the xserver upgrade had broken my nvidia driver. > I only had to reinstall it to solve the problem. > Sorry for the waste of time. I'm glad it's working again. Did you by any chance see exactly why it broke the nvidia driver? Perhaps this could be a bug in either the xserver package or the nvidia driver package? Thierry signature.asc Description: Digital signature
Bug#402545: compiz: Returning from another virtual terminal makes a black screen
* Philippe Perrin wrote: > Package: compiz > Version: 0.2.2-1 > Severity: grave > Justification: renders package unusable > > I log into my Gnome session on virtual terminal 8 (Ctrl+Alt+8). It > starts metacity by default. I start compiz manually (compiz --replace). > I regularly need to switch back to the text consoles (vt1 = Ctrl+Alt+1) > or to another X session (vt7). > When I come back to the X session where compiz was started (vt8), I get > a full black screen, except for my pointer which I can still see moving > (and changing its shape depending on which area of the screen it is). > There is no way for me to leave this black screen (no Ctrl+Alt > combination works). > I use the latest NVIDIA proprietary driver (1.0-9631). I followed the > Debian howto for configuring my Xorg.conf > (http://wiki.debian.org/Compiz). > How can I get rid of this black screen? Thanks! This is likely specific to the NVIDIA driver, but I haven't been able to reproduce this with the NVIDIA driver and compiz 0.3.4, which will probably be uploaded sometime soon. However, it seems that switching to another terminal and back makes compiz crash with the NVIDIA proprietary driver, but that's something you'll have to take up with NVIDIA, it works fine with other open source drivers. Thierry signature.asc Description: Digital signature
Bug#402545: compiz/terminal bug
* Christian Müller wrote: > hello. when i switch back from console to X(.Org 7.1 with nvidia drivers > 1-0.9631) with compiz (0.2.2-1) it crashes the window decorations, AS > SOON AS lots of rams are used, i.e. got a browser with 4-5 tabs open, > plus amarok, plus kopete etc. if only one or no apps are running that > problem does not happen. on the other hand, beryl (with most plugins > deactived) does NOT have that issue (i don't consider it stable either > though). So I guess it's a compiz bug. I cannot reproduce this bug on my notebook with an Intel graphics chipset, so it's not necessarily a compiz bug. You could try compiz 0.3.4, which you can get by running: $ git-clone http://git.debian.org/git/pkg-xorg/app/compiz.git That seems to fix the problem partially. You can build debian packages from that by changing to the 'compiz' directory and running dpkg-buildpackage. Also it may be necessary to run $ apt-get build-dep compiz before trying to build the package. Thierry signature.asc Description: Digital signature
Bug#402545: Nope
* Philippe Perrin wrote: > Using compiz 0.3.4 does not solve my black screen issue... You could try unsetting the compiz gconf settings by running something like this: $ gconftool-2 --recursive-unset /apps/compiz and perhaps for gtk-window-decorator: $ gconftool-2 --recursive-unset /apps/gwd If that doesn't work out, I've heard that removing the gnome config (~/.gnome, ~/.gnome2, ~/.gconf and friends) *may* solve the black screen problem. There seems to be one remaining issue where the NVIDIA driver crashes compiz or the gtk-window-decorator when returning from a VT, but that is more likely a bug in the non-free driver because this does not seem to happen with any of the free drivers. Thierry signature.asc Description: Digital signature
Bug#396498: not fixed in mesa 6.5.1-0.3
reopen 396498 thanks * Steinar H. Gunderson wrote: > Source: mesa > Source-Version: 6.5.1-0.3 > > We believe that the bug you reported is fixed in the latest version of > mesa, which is due to be installed in the Debian FTP archive: [...] > mesa (6.5.1-0.3) unstable; urgency=medium > . >* Non-maintainer upload. >* Build-depend on libx11-dev; fixes FTBFS. (Closes: #396498) [...] As the original bug reporter said, it is not that mesa is missing a build-dependency on libx11-dev (as a matter of fact it already build-depends on libx11-dev) but it is libgl1-mesa-dev that needs to depend on libx11-dev. I am therefore reopening this bug. Thierry signature.asc Description: Digital signature
Bug#390319: compiz: Doesnt refresh windows content
* mateusz wrote: > Package: compiz > Version: 0.0.13+git20060928-2 > Severity: important > > When I run compiz then windows are not refreshed, minimalize and maximalize > force refresh. > > I also get the following output > :~> compiz --replace > libGL warning: 3D driver claims to not support visual 0x4b > /usr/bin/compiz.real: No stencil buffer. Clipping of transformed windows > is not going to be correct when screen is transformed. > /usr/bin/compiz.real: Couldn't load plugin 'gconf' This seems more likely to be your problem. Can you post the output of the following command? $ dpkg -l 'compiz*' This should list the compiz-plugins package, which contains the gconf plugin. If it isn't listed as installed, then try installing it manually, though it should have been installed automatically. Did you install compiz-core directly or did you install via the compiz meta-package? - Thierry signature.asc Description: Digital signature
Bug#390338: compiz: Please not disable kde
* Sune Vuorela wrote: > Package: compiz > Severity: wishlist > > > Hi! > > compiz is build with --disable-kde ; it would be really nice also to > have that option available. Currently the kde-window-decorator is unusable. Note however that it is possible to use the gtk-window-decorator with KDE. - Thierry signature.asc Description: Digital signature
Bug#390728: compiz: X freezes on radeon 9200
* Vedran Furač wrote: > Package: compiz > Version: 0.0.13+git20060928-2 > Severity: important > > Doesn't work for me on radeon 9200 (with open source drivers). X freezes > immediately after I run compiz (or beryl). I can move cursor but without > any interaction. Killing compiz "unfreezes" X. > > In logfile I have: > > AIGLX: 3D driver claims to not support visual 0x23 ... 0x32 Those can safely be ignored. > Other seems fine. You can find xorg.conf attached. Can you attach the output of compiz? You can also try uncommenting the XAANoOffscreenPixmaps in your "Device" section. Not sure it will help, though. - Thierry [...] signature.asc Description: Digital signature
Bug#390814: please remove --strict-binding --indirect-rendering from compiz wrapper
* Vincent Ho wrote: > Package: compiz > Version: 0.0.13+git20060928-2 > Severity: normal > > > I'm using compiz with the binary NVidia drivers. At this HOWTO page for > getting compiz to work with the current version[1], it says you don't > need to use --indirect-rendering (and in fact, that it limits the number > of extensions exposed by the driver). Instead, the page suggests simply > starting with "compiz --replace --use-cow gconf". For those of us who > aren't using AIGLX in stock Xorg drivers, would it be possible to remove > --strict-binding --indirect-rendering from the wrapper script? > > To be honest I'm not really sure why the wrapper is present at all, and > perhaps it should be renamed compiz-wrapper instead of renaming the > binary to compiz.real. The wrapper is present so that people won't have to write their own wrappers. I am totally open to suggestions to add code to the wrapper, though. If you are running the binary nvidia drivers, can you please post the output of the following command: $ glxinfo | grep renderer That'd help me figure out what code to add to the wrapper to make it detect the nvidia driver. - Thierry [...] signature.asc Description: Digital signature
Bug#390814: please remove --strict-binding --indirect-rendering from compiz wrapper
* Michael Biebl wrote: > I second that request. > Imho it would be best to *not* rename the compiz binary to compiz.real, I disagree. Running compiz.real directly only makes sense if you know exactly what you're doing. Running without arguments won't do much good, starting it without running gtk-window-decorator is not what you'd normally want. > but instead provide wrapper scripts like compiz-aiglx (and probably > compiz-nvidia, compiz-xgl) which start compiz with the correct set of > flags for the given environment. I don't like this alternative very much because it will probably duplicate a lot of code in the wrappers. > If you don't want to go this way of distinct wrapper scripts, your > single compiz wrapper script would have to be clever enough to choose > the right set of flags itself. This is more like what I had in mind. Ideally the wrapper should just Do The Right Thing dependending on which server/driver combination is running. - Thierry signature.asc Description: Digital signature
Bug#390929: compiz: "Another window manager is already running on screen: 0"
* Radu Spineanu wrote: [...] > Every time i used to start compiz i got this error: > "Another window manager is already running on screen: 0" > and compiz failed to load. This is usually solved by running compiz with the --replace flag to make it replace any currently running window manager. Does that solve your problem? [...] - Thierry signature.asc Description: Digital signature
Bug#390503: killing gconf helps, unseting not
* Evgeni Golov wrote: > Hi, > > deleting the gconf* and gnome2* folders helps - after that I had > window-borders with compiz. Is this a general compiz/gconf bug, or did > it happen because of the previos installation of compiz from the ubunti > package from compiz.net? I did also run into this bug a couple of days ago, but wasn't able to trace it to its source. I found that it helps to run the following: $ gconftool-2 --recursive-unset /apps/compiz and restart compiz. That way you'll loose all the settings you've changed in compiz, but I guess it's better than deleting the complete gconf and gnome2 directories. I have personally never used the Ubuntu packages, nor the ones from compiz.net, so it's probably unrelated. So far, the only explanation I have is that it might have something to do with installing a new compiz.schemas file, which is what I did before I was hit by the bug. [...] - Thierry signature.asc Description: Digital signature
Bug#390929: compiz: "Another window manager is already running on screen: 0"
* Radu Spineanu wrote: > Hi Thierry, > > Thierry Reding wrote: > > * Radu Spineanu wrote: > > [...] > >> Every time i used to start compiz i got this error: > >> "Another window manager is already running on screen: 0" > >> and compiz failed to load. > > > > This is usually solved by running compiz with the --replace flag to make it > > replace any currently running window manager. Does that solve your problem? > > > I forgot to mention, i was running compiz with --replace. > Without the --replace flag the error was different, asking me to add the > flag to my command. Then this could indicate that whatever window manager you're using does not support being replaced. If deleting kdesktoprc does help, this may be a KDE bug. - Thierry signature.asc Description: Digital signature
Bug#390496: Compiz fails on supersavage on T23 Thinkpad
* DW Price wrote: > Package: compiz > Version: 0.0.13+git20060928-2 > > video: S3 Inc. SuperSavage IX/C SDR - T23 Thinkpad > kernel: 2.6.18-1-686 #1 SMP Sun Sep 24 13:48:23 UTC 2006 i686 GNU/Linux > X Window System Version 7.1.1 > > ** > on running compiz --replace: > > (gtk-window-decorator:15178): Gtk-WARNING **: Unable to locate theme > engine in module_path: "clearlooks", > libGL warning: 3D driver claims to not support visual 0x4b > /usr/bin/compiz.real: Support for non power of two textures missing ^ This indicates that the driver probably doesn't support textures with dimensions that are not powers of two. This is required for compiz to work. I guess this could be reassigned to the S3 driver and have the severity reduced to wishlist perhaps. Anyone? - Thierry signature.asc Description: Digital signature
Bug#391872: compiz: Compiz makes my computer lock up - only hard reboot possible
* Sune Vuorela wrote: > Package: compiz > Version: 0.0.13+git20060928-2 > Severity: important > > > Hi! > > When I do a compiz --replace, my current kwin dissappears as expected, > but then the entire machine locks up completely. The only thing I can do > is a hard reboot. > > I have matrox g550 videocard in a computer with amd3300+ cpu. > > $ grep -i aiglx /var/log/Xorg.0.log > (==) AIGLX enabled > (WW) AIGLX: 3D driver claims to not support visual 0x23 > (WW) AIGLX: 3D driver claims to not support visual 0x24 > (WW) AIGLX: 3D driver claims to not support visual 0x25 > (WW) AIGLX: 3D driver claims to not support visual 0x26 > (WW) AIGLX: 3D driver claims to not support visual 0x27 > (WW) AIGLX: 3D driver claims to not support visual 0x28 > (WW) AIGLX: 3D driver claims to not support visual 0x29 > (WW) AIGLX: 3D driver claims to not support visual 0x2a > (WW) AIGLX: 3D driver claims to not support visual 0x2b > (WW) AIGLX: 3D driver claims to not support visual 0x2c > (WW) AIGLX: 3D driver claims to not support visual 0x2d > (WW) AIGLX: 3D driver claims to not support visual 0x2e > (WW) AIGLX: 3D driver claims to not support visual 0x2f > (WW) AIGLX: 3D driver claims to not support visual 0x30 > (WW) AIGLX: 3D driver claims to not support visual 0x31 > (WW) AIGLX: 3D driver claims to not support visual 0x32 > (II) AIGLX: Loaded and initialized /usr/lib/dri/mga_dri.so So far nothing unusual it seems. > shawn_work in #debians-x gave me a couple of patches to xorg-server > (30_fedora-34_fedora). Those 5 patches didn't help in anyway. > > If I get instructions on how to produce some debugging info, I might > provide that, but remember that my machine locks up completely until > hard reboot. No way at all to access the box anymore? You cannot SSH in for example? You could try and take a look at the Xorg.0.log.old after the reboot, maybe post it here. Not sure that it will be helpful though. - Thierry signature.asc Description: Digital signature
Bug#390271: Resizing and scrolling very slow with r200
* Michel Dänzer wrote: > On Sun, 2006-10-08 at 18:18 +0200, Michel Dänzer wrote: > > On Sat, 2006-10-07 at 21:35 -0400, David Nusinow wrote: > > > > > Ideally though, just editing currently broken-for-EXA patch so > > > that it's only on when XAA is enabled is probably a better hack. > > > > Indeed. > > Actually, it should also be verified that disabling offscreen pixmaps is > even necessary or a good idea with XAA on integrated chipsets, in > particular i[89]xx. It seems to me that enabling offscreen pixmaps on my 852GM/855GM chipset doesn't make a difference, apart from X behaving slightly "different" when starting up compiz. It seems like up until compiz starts rendering, the windows are offset a little more than with offscreen pixmaps disabled. After compiz has loaded, everything is working as normal again, and the performance seems the same. - Thierry signature.asc Description: Digital signature
Bug#390503: small patch in gtk-window-decorator fixed it on my machine
* yoram bar haim wrote: > I have fixed gtk-window-decorator.c to work with RGB24 instead of ARGB32, > this > seems to allow gtk-window-decorator to work (with compiz) on my machine. I > hope it will be usable for everybody > > Here is the diff > 121,123d120 > < /* Added by yoram Bar-Haim, to use with nvidia-9625beta */ > < #define COLOR_DEPTH 24 > < > 2443,2444c2440 > < /* Modified by Yoram Bar-Haim */ > < visual = gdk_visual_get_best_with_depth (COLOR_DEPTH); > --- > > visual = gdk_visual_get_best_with_depth (32); > 2448,2449c2444 > < /* Modified by Yoram Bar-Haim */ > < pixmap = gdk_pixmap_new (NULL, w, h, COLOR_DEPTH); > --- > > pixmap = gdk_pixmap_new (NULL, w, h, 32); > 5275,5277c5270 > < /* Modified by Yoram Bar-Haim */ > < /* all pixmaps are RGB24 */ > < format = XRenderFindStandardFormat (xdisplay, PictStandardRGB24); > --- > > format = XRenderFindStandardFormat (xdisplay, PictStandardARGB32); Does it work if instead of applying the above patch you add the following line to the "Screen" section in your xorg.conf? Option "AddARGBGLXVisuals" "True" I believe that's the "correct" way to configure X for running compiz with the new NVIDIA drivers[0]. It works for me anyway. [...] - Thierry [0]: http://www.nvnews.net/vbulletin/showthread.php?t=77030 signature.asc Description: Digital signature
Bug#390271: Resizing and scrolling very slow with r200
* Michel Dänzer wrote: > On Mon, 2006-10-09 at 17:20 +0200, Thierry Reding wrote: > > * Michel Dänzer wrote: > > > On Sun, 2006-10-08 at 18:18 +0200, Michel Dänzer wrote: > > > > On Sat, 2006-10-07 at 21:35 -0400, David Nusinow wrote: > > > > > > > > > Ideally though, just editing currently broken-for-EXA patch so > > > > > that it's only on when XAA is enabled is probably a better hack. > > > > > > > > Indeed. > > > > > > Actually, it should also be verified that disabling offscreen pixmaps is > > > even necessary or a good idea with XAA on integrated chipsets, in > > > particular i[89]xx. > > > > It seems to me that enabling offscreen pixmaps on my 852GM/855GM chipset > > doesn't make a difference, apart from X behaving slightly "different" when > > starting up compiz. It seems like up until compiz starts rendering, the > > windows are offset a little more than with offscreen pixmaps disabled. > > Define 'offset'. I finally got around to trying this myself, and window > updates were regularly missed. So it seems the problem with XAA > offscreen pixmaps for GLX_EXT_tfp is not just about performance but > correctness. I have set compiz to startup when the GNOME session is loaded, and when compiz replaces metacity, there's a short period where the windows (there's an annoying error message that keeps popping up, but unreleted to compiz or AIGLX) and the desktop are different shades of gray and the window with the error message is first positioned in the top-left corner, then suddenly moves up and to the left. But then, after compiz has loaded and starts updating the window decorations and contents all is back to normal. That is if I comment out the XAANoOffscreenPixmaps option. If it is uncommented, the above "transition" doesn't happen. I'm not sure how helpful this is. After compiz is loaded I don't see any strange behaviour or bad performance with or without XAANoOffscreenPixmaps. - Thierry signature.asc Description: Digital signature
Bug#391592: compiz-core: compiz crashes my X server
* Jeroen van Wolffelaar wrote: > On Sat, Oct 07, 2006 at 03:02:42PM +0200, Eric Van Buggenhaut wrote: > > When running: > > > > compiz -replace > > > > from an xterm window, my X server crashes with this backtrace: > > > > Backtrace: > > 0: X(xf86SigHandler+0x89) [0x80b6849] > > 1: [0xe420] > > 2: X [0x81414a5] > > 3: X(Dispatch+0x19b) [0x8086b8b] > > 4: X(main+0x48e) [0x806e5de] > > 5: /lib/tls/libc.so.6(__libc_start_main+0xc8) [0xb7dc3ea8] > > 6: X(FontFileCompleteXLFD+0xad) [0x806d911] > > > > Fatal server error: > > Caught signal 11. Server aborting > > I get exactly the same. I'm running testing/etch with only compiz and > required dependencies pulled from unstable -> that is, X.org 7.0. AIUI, > compiz requires X.org 7.1, but the dependencies do not reflect this. Yes, compiz-core should depend on xserver-xorg-core (>= 2:1.1.1-9). Can you try that version and see if the problem persists? - Thierry [...] signature.asc Description: Digital signature
Bug#393355: Compiz: Everything is completely white, but plugins work
* Alessio Gaeta wrote: > Subject: compiz: Everything is completely white, but plugins work > Package: compiz > Version: 0.2.0-1 > Severity: grave > Justification: renders package unusable > > > > -- System Information: > Debian Release: testing/unstable > APT prefers testing > APT policy: (850, 'testing'), (800, 'unstable'), (750, 'experimental') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.17-gas-machine > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) > > Versions of packages compiz depends on: > ii compiz-core 0.2.0-1 OpenGL window and compositing mana > ii compiz-gnome0.2.0-1 OpenGL window and compositing mana > ii compiz-gtk 0.2.0-1 OpenGL window and compositing mana > ii compiz-plugins 0.2.0-1 OpenGL window and compositing mana > > compiz recommends no packages. > > -- no debconf information > > When I launch Compiz (with 'compiz --replace', in Gnome), everything > becomes completely white (i.e. no textures at all), but plugins seem to > work correctly: I can switch windows and so on, including (blind) > writing in the console 'metacity --replace'; the only things I can see > are program icons in the switcher. > I'm using the unstable version (6.5.1) of all GL related libraries and > I've updated all Metacity and Gnome packages to unstable. Are you using xserver-xorg-core (>= 2:1.1.1-9) from unstable? Does compiz output errors that it can't bind pixmaps to textures? > All works fine (but windows scrolling and resizing, too slow) with > 0.0.13 git version. That's odd, if you don't use xserver-xorg-core from unstable, 0.0.13 shouldn't work either. Can you provide more info? X server version, compiz output (if any) and maybe /etc/X11/xorg.conf and /var/log/Xorg.0.log? > My graphic card is an ATI Radeon 8500 (r200). > Thanks > -- > Alessio - Thierry signature.asc Description: Digital signature
Bug#393456: compiz: min/max/close window decoration buttons no longer work on upgrade to 0.2.0
* Vincent Ho wrote: > Package: compiz > Version: 0.2.0-1 > Severity: normal > > After upgrading to compiz 0.2.0, the minimise/maximise/close buttons are > still present but inactive. Clicking on them is no different to > clicking elsewhere on the titlebar, it just switches the pointer to a > '+' to indicate I can drag the window around. This means I have to go to > the menus whenever I want to close an application, which is rather > annoying. > > I'm not sure if this is related, but I'm also missing the icon that > shows the window operations menu. Right-clicking the titlebar produces > it, however, as (I think) it did before the upgrade. > > For reference, I'm using the Clearlooks GTK theme, Glider Metacity theme > and Dropline Neu icon theme, and running compiz on the binary Nvidia > drivers. Let me know if I can provide any more info :) Unfortunately I'm unable to reproduce this bug. Are you by any chance running metacity packages from experimental? - Thierry signature.asc Description: Digital signature
Bug#393456: compiz: min/max/close window decoration buttons no longer work on upgrade to 0.2.0
* Vincent Ho wrote: > On Mon, Oct 16, 2006 at 04:27:44PM +0200, Thierry Reding wrote: > > > Unfortunately I'm unable to reproduce this bug. Are you by any chance > > running > > metacity packages from experimental? > > Yes, I confess I am. I wondered about that, but it's no longer running > now since I'm using compiz. Would this be something to do with libwnck? This has most likely something to do with the metacity theme support change from 2.14 -> 2.16. What you could try is install libmetacity-dev from experimental and "apt-get source compiz". Then remove the 012_metacity-theme-support.patch line from compiz-0.2.0/debian/patches/series and rebuild using debuild or dpkg-buildpackage (you may need to run apt-get build-dep compiz first). That should fix things for experimental metacity. HTH. - Thierry signature.asc Description: Digital signature
Bug#391592: compiz-core: compiz crashes my X server
* Jeroen van Wolffelaar wrote: > On Sun, Oct 15, 2006 at 05:19:10PM +0200, Thierry Reding wrote: > > Yes, compiz-core should depend on xserver-xorg-core (>= 2:1.1.1-9). Can you > > try that version and see if the problem persists? > > My system (Thinkpad T41 with radeon9000) locks up hard (not even sysrq > works, only 4 seconds of power button). The only thing I see after > compiz --replace is: "libGL warning: 3D driver claims to not support > visual 0x4b". If the system locks up hard there's probably not much information in the Xorg log, is there? That is, Xorg.0.log.old after the reboot. You could also try to redirect compiz' output to a log file, but that probably won't do any good. It sounds more like a driver issue actually. - Thierry signature.asc Description: Digital signature
Bug#391592: compiz-core: compiz crashes my X server
* Eric Van Buggenhaut wrote: > On Sun, Oct 15, 2006 at 05:19:10PM +0200, Thierry Reding wrote: > > * Jeroen van Wolffelaar wrote: > > > On Sat, Oct 07, 2006 at 03:02:42PM +0200, Eric Van Buggenhaut wrote: > > > > When running: > > > > > > > > compiz -replace > > > > > > > > from an xterm window, my X server crashes with this backtrace: > > > > > > > > Backtrace: > > > > 0: X(xf86SigHandler+0x89) [0x80b6849] > > > > 1: [0xe420] > > > > 2: X [0x81414a5] > > > > 3: X(Dispatch+0x19b) [0x8086b8b] > > > > 4: X(main+0x48e) [0x806e5de] > > > > 5: /lib/tls/libc.so.6(__libc_start_main+0xc8) [0xb7dc3ea8] > > > > 6: X(FontFileCompleteXLFD+0xad) [0x806d911] > > > > > > > > Fatal server error: > > > > Caught signal 11. Server aborting > > > > > > I get exactly the same. I'm running testing/etch with only compiz and > > > required dependencies pulled from unstable -> that is, X.org 7.0. AIUI, > > > compiz requires X.org 7.1, but the dependencies do not reflect this. > > > > Yes, compiz-core should depend on xserver-xorg-core (>= 2:1.1.1-9). Can you > > try that version and see if the problem persists? > > No more crash here ATM, but my Thinkpad is at IBM technical service so > I plugged the HD into my old Tecra (Savage card) and I get this > message: > > /usr/bin/compiz.real: No GLXFBConfig for default depth, this isn't going to > work. > /usr/bin/compiz.real: Failed to manage screen: 0 > /usr/bin/compiz.real: No manageable screens found on display :0 > > As I said this is now a Savage card (no acceleration that I'm aware > of). Should I wait to get my TP back and give it another try with the > r300 card ? Yes, that's the error message you get when DRI is disabled. Compiz just won't run without DRI. I hope this fixes the problems you were seeing on the r300. - Thierry signature.asc Description: Digital signature
Bug#390319: compiz: Doesnt refresh windows content
* Sebastián Lara Menares wrote: > i fix this problem adding: > > Option "XAANoOffscreenPixmaps" > > in Device Section, and Have you tried adding this to you xorg.conf file? This should fix the problem for you. Can you confirm that? - Thierry signature.asc Description: Digital signature
Bug#393355: Problem solved, but new one raised: grave -> important
* Alessio Gaeta wrote: > Hi, thanks for quick reply. > The problems has disappeared re-upgrading Compiz from 0.0.13 to 0.2.0 (I > was following up my own post and I found yours...): don't ask me why, > I'm wondering what's happened. > Anyway now, when I launch 'compiz --replace', gtk-window-decorator > crashes with a segmentation fault, so I don't get windows borders at > all. Disabling the 'use_metacity_theme' in gconf/apps/gwd allow to > gtk-window-decorator to start normally, but of course I don't still have > windows borders. This fact makes me think to a compatibility problem > with Metacity themes. > I'm using the latest version available in Debian repositories of > Metacity related stuff and xserver-xorg-core 2:1.1.1-9. Are you using metacity >= 2.16 from experimental? That *could* explain the problem. Or did you perhaps change anything in the gconf entries for compiz? Are you explicitly specifying the plugins to load on the command-line? Do the effects work for you? That is, do you have wobbly windows? Transparency? Anything? - Thierry signature.asc Description: Digital signature
Bug#396770: compiz: New version available (0.3.2)
* Reine Johansson wrote: > Package: compiz > Version: 0.2.0-1 > Severity: wishlist > > There's a new version (0.3.2) of compiz available at > > http://xorg.freedesktop.org/releases/individual/app/ > > It would be nice with an upgrade. Thanks for the work you put into packaging > compiz for Debian! The current plan is to ship compiz 0.2.2 with etch. That's because 0.2 is the stable branch and the 0.3 development branch is not ready for production use. I do plan to have 0.3.2 uploaded to experimental sometime soon, however, after we've made sure 0.2.2 makes it into etch. Thierry signature.asc Description: Digital signature
