Bug#823020: Bug#823500: cannot boot from ext4

[Thierry Reding]

On Fri, May 06, 2016 at 02:20:45AM +0200, Cyril Brulebois wrote:
> Cyril Brulebois  (2016-05-06):
> > Anyway, we could probably implement the change globally regardless, just
> > to make it possible to check the hypothesis on a wide range of devices,
> > and only figure out later how to fix this in a better way?
> > 
> > Vagrant, what do you think?
> 
> I've pushed a pu/disable-flex_bg branch to partman-ext3's git repository.
> Feedback/tests welcome. I can push to master and upload if that looks like
> a good idea.

I just ran across this from Martin's instructions on how to install
Debian on a Jetson TX1 and this sounds familiar. I ran into a similar
bug not long ago that turned out to be caused by e2fsprogs 1.43 which
enables the 64bit (-O 64bit) feature by default. U-Boot (before 2016.07
I think) can't deal with such filesystems and will read bogus data.

Newer versions of U-Boot have support for this. Another solution was to
create filesystems with -O ^64bit to disable the offending option.

Given that the last entry in this bug report is rather old, I'm not sure
this is still an issue, but I thought I'd bring it up in case this still
doesn't work properly.

Thierry


signature.asc
Description: PGP signature

Bug#400894: FTBFS: tries to write in $HOME

[Thierry Reding]

* 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#400894: FTBFS: tries to write in $HOME

[Thierry Reding]

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 TS (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 @@
 
 project name=sbaz default=build
   !-- Set the following to your local sbaz-managed directory --
-  property name=scala.home  value=${user.home}/sbaz/
+  property name=scala.home  value=/usr/share/
 
-  property name=scala.lib.dir   value=${scala.home}/lib/
+  property name=scala.lib.dir   value=${scala.home}/java/
   property name=junit.jar   value=${scala.lib.dir}/junit.jar/
   property name=servlet-api.jar value=${scala.lib.dir}/servlet-api.jar/
   property name=scala.comp.jar  value=${scala.lib.dir}/scala-compiler.jar/
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#376812: I have a Voodoo2 card...

[Thierry Reding]

* 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 TS 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]

* 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#407055: compiz: manages only screen 0 of a multi screen display

[Thierry Reding]

* 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#394311: Me too

[Thierry Reding]

* 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#402545: Nope

[Thierry Reding]

* 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#402545: compiz/terminal bug

[Thierry Reding]

* 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: compiz: Returning from another virtual terminal makes a black screen

[Thierry Reding]

* 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#401943: Compiz crash problem solved.

[Thierry Reding]

* 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#396498: not fixed in mesa 6.5.1-0.3

[Thierry Reding]

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#396770: compiz: New version available (0.3.2)

[Thierry Reding]

* 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

Bug#393355: Problem solved, but new one raised: grave - important

[Thierry Reding]

* 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#393456: compiz: min/max/close window decoration buttons no longer work on upgrade to 0.2.0

[Thierry Reding]

* 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

[Thierry Reding]

* 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

[Thierry Reding]

* 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#393355: Compiz: Everything is completely white, but plugins work

[Thierry Reding]

* 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

[Thierry Reding]

* 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#391592: compiz-core: compiz crashes my X server

[Thierry Reding]

* 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#390271: Resizing and scrolling very slow with r200

[Thierry Reding]

* 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#390503: small patch in gtk-window-decorator fixed it on my machine

[Thierry Reding]

* 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#391872: compiz: Compiz makes my computer lock up - only hard reboot possible

[Thierry Reding]

* 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

[Thierry Reding]

* 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#390496: Compiz fails on supersavage on T23 Thinkpad

[Thierry Reding]

* 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#390929: compiz: Another window manager is already running on screen: 0

[Thierry Reding]

* 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#390503: killing gconf helps, unseting not

[Thierry Reding]

* 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#390728: compiz: X freezes on radeon 9200

[Thierry Reding]

* 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

[Thierry Reding]

* 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

[Thierry Reding]

* 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

[Thierry Reding]

* 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#390319: compiz: Doesnt refresh windows content

[Thierry Reding]

* 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

[Thierry Reding]

* 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#353263: ITP: freealut -- OpenAL Utility Toolkit

[Thierry Reding]

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#351270: ITP: libgpgme-ruby -- GPGME bindings for the Ruby language

[Thierry Reding]

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#349555: komi - FTBFS: cannot find -lgp

[Thierry Reding]

* 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

[Thierry Reding]

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

[Thierry Reding]

* 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

[Thierry Reding]

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

[Thierry Reding]

* 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

[Thierry Reding]

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

[Thierry Reding]

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...

[Thierry Reding]

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#345616: svn-buildpackage: patch implementing --no-branches

[Thierry Reding]

* Eduard Bloch wrote:
 #include hallo.h
 * 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 @@
 p
 If you actually decide to stop using the mergeWithUpstream-mode, unset the
 mergeWithUpstream property as follows: ttsvn propdel mergeWithUpstream 
debian//tt.
+p
+If you don't want to store the upstream sources of all your packages in the
+repository, you can pass the tt--no-branches/tt switch to
+ttsvn-inject/tt, which will prevent ttsvn-inject/tt from creating a
+ttbranches/tt subdirectory.
 /sect
 
 !--sectImporting directories
@@ -591,7 +596,11 @@
 Put only files that are actually touched in the .diff file under the
 version control.
 svn-inject sets the mergeWithUpstream property automaticaly, see HOWTO.
-
+p
+ em--no-branches/em 
+Do not create the `branches#39; subdirectory. This is useful for repositories
+that store lots of packages and where versioning the upstream sources would
+consume lots of space.
 
 
 
diff -Nur svn-buildpackage-0.6.14.orig/doc/svn-inject.1 
svn-buildpackage-0.6.14/doc/svn-inject.1
--- svn-buildpackage-0.6.14.orig/doc/svn-inject.1   2005-09-10 
21:36:27.0 +0200
+++ svn-buildpackage-0.6.14/doc/svn-inject.12006-01-02 19:10:20.0 
+0100
@@ -36,5 +36,10 @@
 Put only files that are actually touched in the .diff file under the
 version control.
 svn-inject sets the mergeWithUpstream property automaticaly, see HOWTO.
+.TP
+\fB\--no-branches\fR
+Do not create the `branches' subdirectory. This is useful for repositories that
+store lots of packages and where versioning the upstream sources would consume
+lots of space.
 .SH SEE ALSO
 svn\-buildpackage(1), svn\-upgrade(1), svn(1), the HOWTO manual (in 
/usr/share/doc/svn-buildpackage/).


signature.asc
Description: Digital signature

Bug#345616: svn-buildpackage: patch implementing --no-branches

[Thierry Reding]

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

[Thierry Reding]

* Eduard Bloch wrote:
 #include hallo.h
 * 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#342466: ITP: rcairo -- Cairo bindings for the Ruby language

[Thierry Reding]

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#323028: fetchmail: manpage typos

[Thierry Reding]

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#295289: billard-gl: impossible to hit ball at full strength

[Thierry Reding]

* 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=4i=1t=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#293687: billard-gl: keyrepeat makes shooting impossible

[Thierry Reding]

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#173197: Workaround

[Thierry Reding]

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#291738: Fix

[Thierry Reding]

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#236582: I intend to adopt billard-gl

[Thierry Reding]

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