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#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 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...
* 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 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#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#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#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#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#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#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#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 21
+clean_symlinks /var/lib/lists-archives
# Fix stray ownerships and permissions (searchlists.log must be
