Bug#401051: seems to be a dupe
this appears to be a dupe of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402407
Bug#401266: Bug#393422: Contains non-free files
if you belive that the files used to build debians packages are free then wouldn't the obvious thing to do be to remove everything else from the source packages? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387852: gaim 2 for etch
package: gaim severity: wishlist it seems crazy to me to have a package from an abandoned (at least i get the impression its abandoned from #gaim and similar) series and especially a cvs snapshot of the abandoned series going into a stable distribution. It seems like it would make far more sense to have the 2.0.0 betas in. i notice that the gaim 2 betas are already in experimental, what if anything are the issues that are making you keep them out of unstable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397593: looks like another instance of sending non utf-8 text to dbus
tags 39753 patch thanks note: this reply is to the first message in this bug, the second message looks like it could be a seperate (but most likely similar) issue. from the most recent changelog: * 06_irc-signal-crash.patch: - Add patch to work around crash on receiving non-ASCII characters in IRC by not emitting the new irc-receiving-text signal; the text from the server needs to be normalized into proper UTF-8 before sending it to dbus. from looking at the backtrace and the source it seems there is an irc-sending-text signal that also needs to be disabled, i've attatched a modified version of the irc signal crash patch and put a set of debs at http://plugwash.bircd.org/gaimirccrashfix/ for testing, can the reporters of this bug please test if my change fixes their problem. 06_irc-signal-crash.patch Description: Binary data
Bug#394773: beta5 now in unstable
retitle 394773 support for the gaim 2.0.0beta5 required. thanks just to let you know that what is now needed is beta5 support, since beta5 has replaced beta4 in sid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#260420: libsilc has now been repackaged
and it seems the guy who did it this time understands that libraries have versions.
Bug#393578: netbase should be split
Package: netbase Severity: normal right now netbase is mostly but not quite a metapackage. this is a pita for those of us trying to maintain slim chroot environments, some of the files in netbase are needed by tools like ftp which give strange errors if they are not present but netbase has a huge list of dependencies that really aren't needed inside a chroot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394773: this sounds like an ideal candidate for a nmu
retitle 394773 minor change needed for compatibility with gaim2.0.0beta4 thanks this sounds like an ideal candidate for a nmu, i've changed that title as it misleadingly implied that a binnmu would have fixed this.
Bug#396612: please loosen up dependency on gaim-data
package:gaim severity:normal right now gaim and gaim-dev use a == dependency on gaim-data. because gaim and gaim-dev are arch any while gaim-data is arch all when a new version of gaim is uploaded gaim becomes temporally uninstallable on most architectures. This causes a LOT of buildd failures for packages that depend on gaim. is there any particular reason this needs to be an == dependency rather than just a = ? all gaim-data seems to contain is a load of translations are theese highly version sensitive?
Bug#196729: old bug, whats the status?
you reported this bug over 3 years ago and gaim has changed a lot in that time. If you are still experiancing the crashes with the current version of gaim please provide more recent backtraces, otherwise please close the bug -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#264688: looks like an endian screwup, is it still happening?
this looks like a UCS2/UTF-16 endian screwup (a-z all map to cjk ideographs when byteswapped and - and . both map to characters from strange languages that you probablly won't have fonts for) is this issue still happening with 2.0.0beta4? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354622: gnuzilla iceweasel project
i'm guessing from the comment Also, they distribute non-free software as plug-ins that gnuzilla has messed with the plugin finder, is this something that debian wants? (it seems like it would interfere with a lot of users who wan't stuff like flash to work) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390352: missing dependency on netbase
Package: ftp Version: 0.17-12 Severity: important netbase contains /etc/services which ftp needs to run but ftp doesn't depend on it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij
package: gij-4.1 severity: grave the buildd log in question is at http://buildd.debian.org/fetch.php?pkg=guificationsver=2.13%7Ebeta3-0.1ar ch=powerpcstamp=1159970889file=logas=raw, the following is an extract from that log Setting up gij-4.1 (4.1.1-15) ... gcj-dbtool-4.1: error while loading shared libraries: libgcj.so.70: cannot open shared object file: No such file or directory dpkg: error processing gij-4.1 (--configure): subprocess post-installation script returned error exit status 2 dpkg: dependency problems prevent configuration of ecj-bootstrap: ecj-bootstrap depends on gij-4.1 (= 4.1.1-13); however: Package gij-4.1 is not configured yet. dpkg: error processing ecj-bootstrap (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of ecj-bootstrap-gcj: ecj-bootstrap-gcj depends on ecj-bootstrap (= 3.2.1-1); however: Package ecj-bootstrap is not configured yet. dpkg: error processing ecj-bootstrap-gcj (--configure): dependency problems - leaving unconfigured the line that appears to be the root of the problem is gcj-dbtool-4.1: error while loading shared libraries: libgcj.so.70: cannot open shared object file: No such file or directory dpkg: error processing gij-4.1 (--configure): this seems to indicate that gij-4.1's configure script is depending on libgcj.so.70 but it hasn't been installed at that point for some reason. i belive the soloution is to make gij-4.1 pre-depend on libgcj7-0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391244: this package is finished with
sametime support is now a built in feature of the main gaim package so this package should be reduced to a dummy for ease of upgrading. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391242: patch for building on gaim
tags 391242 +patch thanks. making this build against 2.0.0beta3.1 in my sid chroot was pretty easy, i just nicked some headers that are no longer in the official public interface of gaim from the gaim source package (yes eliminating the dependance on non public interfaces is a good move long term but i'm not enough of an expert to do that), renamed them made some minor tweaks to use them and it built. actually making the patch work with the build system was easier said than done but now its done just add it to the debian/patches dir to use it. i installed the package and gaim recognised it and gave me a rvp option in the accounts dialog. I can't test beyond that because i don't have a suitable server to use it with. buildwithgaim2.0.patch Description: Binary data
Bug#391244: removal from unstable
since my previous message i have been advised that because this package already depended on gaim it should be removed from unstable rather than converted into a dummy. i've been told that such removal requests are made by submitting a bug on the ftp.debian.org psudo package, if noone objects within a few days i will do this for this package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391569: please remove gaim-meanwhile from unstable
package: ftp.debian.org Serverity: Serious per bug #391244 gaim-meanwhile is now redundant (since its functionality has been integrated into gaim) and is blocking gaim2 from entering testing. Please remove it from unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij
a buildd problem, not a package problem; will be fixed tonight. has this been fixed and if so has the guifrications build been requeued? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400052: another dupelicate
severity 400052 grave reassign 400052 gaim-autoprofile merge 400052 394773 thanks Debian Bug report logs source autoprofile.URL Description: Binary data
Bug#397788: for the benifit of the testing scripts
found 397788 mailto:[EMAIL PROTECTED]1:2.0.0+beta5-1 Thanks the testing scripts seem to think this is not in beta5-1, hopefully this message will fix that problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502636: python-reportlab: FTBFS with binary-arch build
tags 502636 +patch thanks It seems this package just changed from being purely arch independent to also building some arch dependent packages. The build-depends-indep line needs changing to simply build-depends so the packages are availible when building the arch dependent packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496587: error while upgrading ca-certificates
package: ca-certificates severity: normal While doing regular updates using update-manager on my lenny system I got the following error Setting up ca-certificates (20080809) ... Updating certificates in /etc/ssl/certsdone. Running hooks in /etc/ca-certificates/update.dCertificate already exists in keystore under alias root Do you still want to add it? [no]: keytool error: java.lang.IllegalArgumentException dpkg: error processing ca-certificates (--configure): subprocess post-installation script returned error exit status 1 Setting up fastjar (2:0.95-2) ... Despite the error dpkg seems to think the package was installed succesfully and apt-get -f install reports nothing to do. Since nothing actually seems broken I am only reporting this as normal feel free to up severity if desired. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496587: error while upgrading ca-certificates
Please run the following:
for i in /etc/ca-certificates/update.d/*; do dpkg -S $i; echo $i;
cat $i; done
This looks like a bug in another package adding certificates from
ca-certificates into its own (Java-ish) truststore...
debian:/home/plugwash# for i in /etc/ca-certificates/update.d/*; do dpkg
-S $i;
echo $i;
cat $i; done
ca-certificates-java: /etc/ca-certificates/update.d/jks-keystore
/etc/ca-certificates/update.d/jks-keystore
#! /bin/sh
set -e
JAVA_HOME=/usr/lib/jvm/java-6-openjdk
KEYTOOL=$JAVA_HOME/bin/keytool
KEYSTORE=/etc/ssl/certs/java/cacerts
# read lines of the form: [+-]/etc/ssl/certs/*.pem
while read line; do
pem=${line#[+-]*}
alias=$(basename $pem .crt | tr A-Z a-z | tr -cs a-z0-9 _)
alias=${alias%*_}
case $line in
+*)
$KEYTOOL -importcert -trustcacerts --keystore $KEYSTORE \
-storepass 'changeit' \
-alias $alias -file $pem
;;
-*)
$KEYTOOL -delete --keystore $KEYSTORE \
-storepass 'changeit' \
-alias $alias
;;
*)her
echo 2 $0: Unknown line $line
esac
done
debian:/home/plugwash#
I wonder if this is related to the fact that I have
openjdk/ca-certificates-java but due to some other testing I was doing
my java alternatives currently point at java-gcj-compat
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496764: please remove azureus-gcj
package: ftp.debian.org azureus-gcj has been dropped from the azureus source as it was useless (azureus doesn't work with gij) but old binaries are still in the archive. Please remove them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493411: fix for 493411 (sysfence FTBFS with dash)
tags 493411 +patch thanks replace the parseopt= and sys= lines near the top of the makefile with the following to fix this bug parseopt=parseopt/confread.o parseopt/lex.o parseopt/parse.o sys=sys/exit.o sys/xalloc.o sys/log.o sys/communication.o sys/sighandlers.o sys/processtitle.o sys/users.o -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496981: win32-loader fails if a directory already exists who's name matches debian in windows case insenstive matching but not in grubs matching (Which I presume is case sensive)
package: win32-loader severity: important justification: renders the package unusable for some users. according to [EMAIL PROTECTED] win32-loader will use an existing directory that matches debian in the windows filesystem. Unfortunately grub's filename matching and windows are different leading to grub failing to find the files. I am filing a bug to track this issue -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493453: fix for 493453 (bootcd FTBFS with dash)
tags 493453 +patch thanks change /bin/sh to /bin/bash on line 83 of the Makefile to fix this bug -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496981: Case sensitive path name in windows based installer
[EMAIL PROTECTED] wrote: I run the windows based installer but after reboot grub won't boot and shown his prompt. After a little investigation I discovered grub was asked to look for image files to load from a debian directory in the Windows disk but they were in Debian directory instead. This probably happened because there was already a Debian directory on that disk created by me for some reasons in the past. The windows based installer program then copied image files to that directory without being aware it was already existing but was having a different case in his name. To solve the problem I booted into Windows then renamed the Debian directory to debian using the Windows file manager, then I rebooted the system the installation process started and completed successfully. It seems like the proper way to fix this is to find out from windows what the file is actually called (including case) and use that information when writing the grub config. Maybe GetLongPathName will do what is required. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497120: bug cloning no longer displayed correctedly
package: bugs.debian.org severity: important. The bug number of the clone seems to be missing from the clone message on bugs.debian.org . This makes it rather hard to find the clone when following a bugreport. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497131: [jcc] Please add ${python:Depends} to Depends field
found 497131 1.9-1 thanks this bug also affects the version currently in testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501048: coco-cpp - FTBFS: rm: cannot remove `Coco': No such file or directory
tags 501048 +patch thanks this bug is trivial to fix, just change rm Coco to rm -f Coco in the clean target in the Makefile -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501207: destar doesn't start, backtrace shown
ii python 2.5.2-2 An interactive high-level object-o Shouldn't we make destar conflict with python 2.5? No that would just make the package uninstallable. If the package really can't be used with python 2.5 then it should explicitly depend on python 2.4 and be modified to explitly use it. However in general using an earlier version of a compiler or library to work arround a bug should be regarded as a last resort soloution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498053: fslview ftbfs on arm due to a segfault in libQVTKWidgetPlugin.so which is called into from uic-qt3
tags 498053 +patch forcemerge 498053 492538 thanks disabling optimisation seems to fix this, attatched is a patch to do so for arm only. diff -ur vtk-5.0.4/debian/rules vtk-5.0.4.new/debian/rules --- vtk-5.0.4/debian/rules 2008-10-08 20:26:39.0 +0100 +++ vtk-5.0.4.new/debian/rules 2008-10-06 22:20:33.0 +0100 @@ -28,13 +28,23 @@ export TCLLIBPATH=$(CURDIR)/Build/Wrapping/Tcl/ export CFLAGS=-g -Wall +DEB_BUILD_ARCH ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH) + ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) -CFLAGS += -O0 -CXXFLAGS += -O0 + CFLAGS += -O0 + CXXFLAGS += -O0 else -CFLAGS += -O2 -CXXFLAGS += -O2 + #optimisation seems to cause a segfault on + #arm old abi so disable it + ifeq ($(DEB_BUILD_ARCH),arm) + CFLAGS += -O0 + CXXFLAGS += -O0 + else + CFLAGS += -O2 + CXXFLAGS += -O2 + endif endif + ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif
Bug#492121: probable fix for 492121
I think adding the following to the work target in debian/rules just before the last line should make this package build succesfully cp /usr/share/misc/config.sub work.tmp cp /usr/share/misc/config.guess work.tmp Unfortunately since I have been unable to reproduce the problem (it seems to be specific to 64 bit mips and qemu-system-mips64 seems very slow and crash prone) I cannot confirm if this fix works or not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492455: fix for 492455
tags 492455 +patch thanks The attatched debian/rules file has been modified to only build that plugin on i386 only (I don't think any via chips support amd64 and even if they do the current padlock code won't build on it) #!/usr/bin/make -f # Sample debian/rules that uses debhelper. # GNU copyright 1997 to 1999 by Joey Hess. # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 export DH_OPTIONS # this is a security-critical package, set all the options we can export DEB_BUILD_HARDENING=1 CONFIGUREARGS := --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ --libexecdir=/usr/lib \ --enable-http --enable-ldap \ --enable-nonblocking --enable-thread \ --enable-smartcard --enable-cisco-quirks \ --with-default-pkcs11=/usr/lib/opensc-pkcs11.so \ --enable-xml \ --enable-p2p --enable-manager \ --enable-openssl # Could enable --enable-nat-transport, but this is actually insecure, # so don't! # And for --enable-eap-sim we would need the library, which we don't # have right now. DEB_BUILD_ARCH_CPU ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU) #the padlock plugin only makes sense on i386 ifeq ($(DEB_BUILD_ARCH_CPU),i386) CONFIGUREARGS += --enable-padlock endif configure: configure-stamp configure-stamp: patch dh_testdir # Add here commands to configure the package. ./configure $(CONFIGUREARGS) touch configure-stamp patch: dh_testdir dpatch apply-all unpatch: dpatch deapply-all build: build-stamp build-stamp: configure-stamp $(MAKE) touch build-stamp clean: unpatch dh_testdir dh_testroot rm -f build-stamp configure-stamp -$(MAKE) clean #-$(MAKE) -C programs/fswcert/ clean # after a make clean, no binaries _should_ be left, but -find $(CURDIR) -name *.o | xargs --no-run-if-empty rm -find $(CURDIR)/lib/libcrypto -name *.a | xargs --no-run-if-empty rm # Really clean (#356716) # This is a hack: should be better implemented rm -f lib/libstrongswan/libstrongswan.a || true rm -f lib/libstrongswan/liboswlog.a || true # just in case something went wrong rm -f $(CURDIR)/debian/ipsec.secrets # and make sure that template are up-to-date debconf-updatepo dh_clean install-strongswan: DH_OPTIONS=-a install-strongswan: build-stamp dh_testdir dh_testroot dh_installdirs # Add here commands to install the package into debian/tmp. $(MAKE) install DESTDIR=$(CURDIR)/debian/strongswan install --mode=0600 $(CURDIR)/debian/ipsec.secrets.proto $(CURDIR)/debian/strongswan/etc/ipsec.secrets # also patch ipsec.conf to include the debconf-managed file echo $(CURDIR)/debian/strongswan/etc/ipsec.conf echo include /var/lib/strongswan/ipsec.conf.inc $(CURDIR)/debian/strongswan/etc/ipsec.conf # and to enable both IKEv1 and IKEv2 by default sed -r 's/^[ \t]+# *plutostart=(yes|no) */\tplutostart=yes/;s/^[ \t]+# *charonstart=(yes|no) */\tcharonstart=yes/' $(CURDIR)/debian/strongswan/etc/ipsec.conf $(CURDIR)/debian/strongswan/etc/ipsec.conf.tmp mv $(CURDIR)/debian/strongswan/etc/ipsec.conf.tmp $(CURDIR)/debian/strongswan/etc/ipsec.conf # this is handled by update-rc.d rm -rf $(CURDIR)/debian/strongswan/etc/rc?.d dh_installdocs -pstrongswan -n # change the paths in the installed doc files (but only in regular # files, not in links to the outside of the build tree !) # TODO: check if we still need this ( cd $(CURDIR)/debian/strongswan/; \ for f in `grep /usr/local/ --recursive --files-with-match *`; \ do \ if [ -f $$f -a ! -L $$f ]; then \ cp $$f $$f.old; \ sed 's/\/usr\/local\//\/usr\//' $$f.old $$f; \ rm $$f.old; \ fi; \ done ) # the logcheck ignore files install -D --mode=0600 $(CURDIR)/debian/logcheck.ignore.paranoid $(CURDIR)/debian/strongswan/etc/logcheck/ignore.d.paranoid/strongswan install -D --mode=0600 $(CURDIR)/debian/logcheck.ignore.server $(CURDIR)/debian/strongswan/etc/logcheck/ignore.d.server/strongswan install -D --mode=0600 $(CURDIR)/debian/logcheck.ignore.server $(CURDIR)/debian/strongswan/etc/logcheck/ignore.d.workstation/strongswan install -D --mode=0600 $(CURDIR)/debian/logcheck.violations.ignore $(CURDIR)/debian/strongswan/etc/logcheck/violations.ignore.d/strongswan # set permissions on ipsec.secrets chmod 600 $(CURDIR)/debian/strongswan/etc/ipsec.secrets #chmod 644 $(CURDIR)/debian/strongswan/etc/ipsec.conf chmod 700 -R
Bug#492530: jbidwatcher: is this DFSG compatible ?
http://www.jbidwatcher.com/commercial_resale.shtml Doesn't that make jbidwatcher non-free ? Afaict no because it is not a part of the license just a request. In addition, although /not/ as a legal license addendum As several people have asked, this isn't an addendum to the license Looks like jbidwatcher 2.0 will be non-free though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491563: current openjdk-6 packages fail to build
the current packages fail to build using the openjdk-6 in the archive, or using the ecj based bootstrap. Looks like the package is now building successfully on all architectures it has ever built successfully on. Should this bug now be closed (or if the build was fixed by a workarround possiblly downgraded instead) so openjdk can make it into lenny? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482946: apache2-mpm-itk FTBFS in experimental chroot
reopen 482946 thanks ...which I'm pretty sure has been fixed now, so I'm closing it. I just updated my experimental amd64 chroot and tried to build the latest version of apache2-mpm-itk and it failed with the same error as before. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486654: adonthell: FTBFS on arm and armel
Anyway, given that 0.3.4.cvs.20050813-3 compiled but 0.3.4.cvs.20050813-4 didn't, I guess this is somehow related to gcc-4.3. It looks like the default python version also changed between the two builds from 2.4 to 2.5 so that would be a suspect too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492751: Lenny beta 2 dies on boot up
I have successfully loaded an earlier build of lenny on the same hardware. Checking Google, I found a long discussion of the problem at: http://www.gossamer-threads.com/lists/linux/kernel/949548 This suggests that the lenny beta 2 kernel may not work with my processor. Is this something that needs to be fixed by kernel team? Or, is there something I need to do to get around it Could you try installing in expert mode and explicitly selecting the 486 kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486654: adonthell: FTBFS on arm and armel
tags 486654 +patch
thanks
Rebuilding with gcc-4.2 fails in the same way, so I guess it is due to
Python changes.
The package builds succesfully on arm (I don't have armel availible to
test but I presume the issue is the same on both) with python2.4. I have
attatched a patch to make it use python 2.4 on arm and armel.
diff -ur adonthell-0.3.4.cvs.20080529/debian/control adonthell-0.3.4.cvs.20080529.new/debian/control
--- adonthell-0.3.4.cvs.20080529/debian/control 2008-07-28 18:31:56.0 +
+++ adonthell-0.3.4.cvs.20080529.new/debian/control 2008-07-28 08:42:39.0 +
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Debian Games Team [EMAIL PROTECTED]
Uploaders: Barry deFreese [EMAIL PROTECTED]
-Build-Depends: debhelper (= 5.0.37.2), autotools-dev, libsdl1.2-dev, libvorbis-dev, zlib1g-dev, swig1.3 (= 1.3.14), libfreetype6-dev, libaa1-dev, python-dev (= 2.3.5-11), python-support (= 0.4.0), libsdl-ttf2.0-dev, libsdl-mixer1.2-dev, libsdl1.2-dev, quilt
+Build-Depends: debhelper (= 5.0.37.2), autotools-dev, libsdl1.2-dev, libvorbis-dev, zlib1g-dev, swig1.3 (= 1.3.14), libfreetype6-dev, libaa1-dev, python-dev (= 2.3.5-11), python-support (= 0.4.0), libsdl-ttf2.0-dev, libsdl-mixer1.2-dev, libsdl1.2-dev, quilt, python2.4-dev [arm armel]
Standards-Version: 3.7.3
Homepage: http://adonthell.linuxgames.com/
Vcs-Svn: ssh://svn.debian.org/svn/pkg-games/packages/trunk/adonthell/
diff -ur adonthell-0.3.4.cvs.20080529/debian/rules adonthell-0.3.4.cvs.20080529.new/debian/rules
--- adonthell-0.3.4.cvs.20080529/debian/rules 2008-07-28 18:31:56.0 +
+++ adonthell-0.3.4.cvs.20080529.new/debian/rules 2008-07-28 17:44:17.0 +
@@ -8,7 +8,23 @@
CFGDEBUG =
INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL} -p -o root -g root -m 755
-PYVERSION=$(shell pyversions -d)
+
+PYVERSIONNN:=$(shell pyversions -d -v)
+
+
+#for some reason when adonthell embeds python2.5 on arm(el) it fails to init
+#so use python2.4 there for now
+DEB_BUILD_ARCH_CPU ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU)
+
+ifeq ($(DEB_BUILD_ARCH_CPU),armel)
+ PYVERSIONNN :=2.4
+endif
+
+ifeq ($(DEB_BUILD_ARCH_CPU),arm)
+ PYVERSIONNN :=2.4
+endif
+
+PYVERSION :=python$(PYVERSIONNN)
ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CXXFLAGS += -g
@@ -98,7 +114,7 @@
dh_installmenu
dh_installman debian/adonthell.6
dh_installchangelogs ChangeLog
- dh_pysupport -V $(shell pyversions -d -v) adonthell /usr/share/games/adonthell/modules/
+ dh_pysupport -V $(PYVERSIONNN) adonthell /usr/share/games/adonthell/modules/
dh_link
dh_strip
dh_compress
Bug#463277: afnix is buildable on arm using gcc 4.1 ,patch attatched to make build process use it on arm
tags 463277 +patch
thanks
I tried to debug this by adding printf statements and came to the
conclusion that it appears to be a compiler bug. It crashed during a
call to a callback. Adding printf statements to that callback stopped it
crashing (but it went on to crash in another similar callback)
Givent this suspicion I tried disabling optimisation. This was a little
tricky as though there was a CFLAGS set in debian/rules it didn't seem
to have any affect on the build process. However that did not fix it.
I established that the last time a buildd successfully built this on arm
it used gcc-4.1 and afaict the buildds never tried to build it with 4.2.
So the next thing I tried was using older gcc versions 4.2 failed and
4.1 works
A patch to make afnix build using g++-4.1 on arm has been attatched.
Note: my testing was done in qemu, I don't have access to real arm hardware.
diff -urN afnix-1.5.2/cnf/mak/afnix-gcc-4.1.mak afnix-1.5.2.new/cnf/mak/afnix-gcc-4.1.mak
--- afnix-1.5.2/cnf/mak/afnix-gcc-4.1.mak 1970-01-01 00:00:00.0 +
+++ afnix-1.5.2.new/cnf/mak/afnix-gcc-4.1.mak 2008-07-29 14:34:51.0 +
@@ -0,0 +1,157 @@
+#
+# - afnix-gcc-4.2-
+# - afnix compiler configuration - forced gcc 4.1 configuration -
+# - created by peter green based on afnix-gcc-4.mak to workarround a build -
+# - issue on arm
+#
+# - This program is free software; you can redistribute it and/or modify -
+# - it provided that this copyright notice is kept intact. -
+# - -
+# - This program is distributed in the hope that it will be useful, but -
+# - without any warranty; without even the impliedwarranty of -
+# - merchantability or fitness for a particular purpose. In not event shall -
+# - the copyright holder be liable for any direct, indirect, incidental or -
+# - special damages arising in any way out of the use of this software. -
+#
+# - copyright (c) 1999-2007 amaury darsch-
+#
+
+#
+# - compiler and linker section -
+#
+
+CC = g++-4.1
+LD = gcc-4.1
+LK = gcc-4.1
+AR = ar
+RANLIB = ranlib
+STDEVFLAGS =
+STDCCFLAGS = -Wall -fno-builtin
+STACCFLAGS =
+DYNCCFLAGS = -fPIC
+PLTCCFLAGS = -MMD
+DEBUGFLAGS = -g
+OPTCCFLAGS = -O2
+PFLCCFLAGS = -g -pg
+COVCCFLAGS = -g -fprofile-arcs -ftest-coverage
+CPPCCFLAGS = -nostdinc -nostdinc++
+CXXCCFLAGS =
+STDDEFINES = -D_REENTRANT
+DBGDEFINES = -DDEBUG
+OPTDEFINES =
+STDINCLUDE =
+AFXCPPTYPE = GNU
+AFXCPPVERS = 4
+
+#
+# - compiler dependant libraries -
+#
+
+# adjust for darwin platform
+ifeq ($(PLATNAME),darwin)
+PLTSDKROOT = $(SDKDIR)
+PLTSDKARCH = -arch ppc -arch i686
+PLTCCFLAGS = -isysroot ${PLTSDKROOT} $(PLTSDKARCH)
+PLTLDFLAGS = $(PLTCCFLAGS)
+PLTLKFLAGS = $(PLTCCFLAGS)
+PLTEVFLAGS = MACOSX_DEPLOYMENT_TARGET=10.4
+endif
+
+#
+# - platform dependant linking flags -
+#
+
+# adjust for linux platform
+ifeq ($(PLATNAME),linux)
+ARFLAGS = rc
+LDFLAGS = -shared
+ifeq ($(LKMODE),soname)
+LDFLAGS += -Wl,-soname,$(SONAME)
+endif
+AFXCPPLIBS = -lsupc++
+endif
+
+# adjust for solaris platform
+ifeq ($(PLATNAME),solaris)
+ARFLAGS = rc
+LDFLAGS = -shared
+ifeq ($(LKMODE),soname)
+LDFLAGS += -Wl,-h,$(SONAME)
+endif
+AFXCPPLIBS = -lsupc++
+endif
+
+# adjust for freebsd platform
+ifeq ($(PLATNAME),freebsd)
+LD = g++
+LK = g++
+ARFLAGS = rc
+LDFLAGS = -shared
+ifeq ($(LKMODE),soname)
+LDFLAGS += -Wl,-soname,$(SONAME)
+endif
+AFXCPPLIBS =
+endif
+
+# adjust for darwin platform
+ifeq ($(PLATNAME),darwin)
+LD = g++
+LK = g++
+ARFLAGS = -rc
+LDFLAGS = -dynamiclib $(PLTLDFLAGS)
+ifeq ($(LKMODE),dylib)
+LDFLAGS += -compatibility_version $(MAJOR).$(MINOR)
+LDFLAGS+= -current_version $(MAJOR).$(MINOR).$(PATCH)
+else
+$(error, undefined darwin linking mode)
+endif
+AFXCPPLIBS =
+endif
+
+# adjust for gnu
Bug#482946: closed by Stefan Fritsch [EMAIL PROTECTED] (Bug#482946: fixed in apr-util 1.3.2+dfsg-1)
#482946: apache2-mpm-itk FTBFS in experimental chroot It has been closed by Stefan Fritsch [EMAIL PROTECTED]. I can confirm that this is indeed fixed and apache2-mpm-itk once again builds in my experimental chroot. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486654: FTBFS blocking RC bug fixes
It is indeed required on armel but your patch is buggy.
You need to use DEB_BUILD_ARCH instead of DEB_BUILD_ARCH_CPU,
which is arm on both, whilc D_B_A is arm or armel
Good to know.
Actually your patch works fine, since D_A_B_CPU matches arm both on
arm and on armel. My apologies
While it will as you say work it is not good to have a block of code
that will both never match anything and will
confuse anyone who reads it. I have attatched an updated one with a
comment added and the armel test block removed.
BTW are you a DD and able to upload the patches for the bugs in
adonthell and afnix?
diff -ur adonthell-0.3.4.cvs.20080529/debian/control adonthell-0.3.4.cvs.20080529.new/debian/control
--- adonthell-0.3.4.cvs.20080529/debian/control 2008-07-28 18:31:56.0 +
+++ adonthell-0.3.4.cvs.20080529.new/debian/control 2008-07-28 08:42:39.0 +
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Debian Games Team [EMAIL PROTECTED]
Uploaders: Barry deFreese [EMAIL PROTECTED]
-Build-Depends: debhelper (= 5.0.37.2), autotools-dev, libsdl1.2-dev, libvorbis-dev, zlib1g-dev, swig1.3 (= 1.3.14), libfreetype6-dev, libaa1-dev, python-dev (= 2.3.5-11), python-support (= 0.4.0), libsdl-ttf2.0-dev, libsdl-mixer1.2-dev, libsdl1.2-dev, quilt
+Build-Depends: debhelper (= 5.0.37.2), autotools-dev, libsdl1.2-dev, libvorbis-dev, zlib1g-dev, swig1.3 (= 1.3.14), libfreetype6-dev, libaa1-dev, python-dev (= 2.3.5-11), python-support (= 0.4.0), libsdl-ttf2.0-dev, libsdl-mixer1.2-dev, libsdl1.2-dev, quilt, python2.4-dev [arm armel]
Standards-Version: 3.7.3
Homepage: http://adonthell.linuxgames.com/
Vcs-Svn: ssh://svn.debian.org/svn/pkg-games/packages/trunk/adonthell/
diff -ur adonthell-0.3.4.cvs.20080529/debian/rules adonthell-0.3.4.cvs.20080529.new/debian/rules
--- adonthell-0.3.4.cvs.20080529/debian/rules 2008-07-28 18:31:56.0 +
+++ adonthell-0.3.4.cvs.20080529.new/debian/rules 2008-07-31 22:32:14.0 +
@@ -8,7 +8,20 @@
CFGDEBUG =
INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL} -p -o root -g root -m 755
-PYVERSION=$(shell pyversions -d)
+
+PYVERSIONNN:=$(shell pyversions -d -v)
+
+
+#for some reason when adonthell embeds python2.5 on arm(el) it fails to init
+#so use python2.4 there for now
+DEB_BUILD_ARCH_CPU ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU)
+
+#note: DEB_BUILD_ARCH_CPU is arm on both arm and armel
+ifeq ($(DEB_BUILD_ARCH_CPU),arm)
+ PYVERSIONNN :=2.4
+endif
+
+PYVERSION :=python$(PYVERSIONNN)
ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CXXFLAGS += -g
@@ -98,7 +111,7 @@
dh_installmenu
dh_installman debian/adonthell.6
dh_installchangelogs ChangeLog
- dh_pysupport -V $(shell pyversions -d -v) adonthell /usr/share/games/adonthell/modules/
+ dh_pysupport -V $(PYVERSIONNN) adonthell /usr/share/games/adonthell/modules/
dh_link
dh_strip
dh_compress
Bug#493341: Fix for 493341 (and a couple of other fixes you might want to apply)
tags 493341 +patch thanks add bioperl to the build-depends to fix this bug. you might also want to add libgd-gd2-perl to the build-depends to fix the following warning - WARNING - GD.pm does not seem to be installed. GD is reqired to produce sequence logos from information content matrices. If you need this functionality, please visit http://stein.cshl.org/WWW/software/GD/ for information on obtaining and installing GD. - The package also FTBFS if built twice in a row because after a build the clean target prompts for user input. I this can be fixed by removing unpatch from the dependencies of the clean target and adding debian/rules unpatch to the end of the clean target. note: while this bug was reported from a s390 buildlog it seems to be a general problem (it failed on every autobuiler that tried to build it). My testing was done on amd64. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493300: blobandconquer crashes on startup on i386
The attached patch fixes this (with casts etc.) for at least these two architectures, but it still needs correction for big-endian systems. It should (probably) be reworked a little to properly serialise the reading writing within the FileData class. Why not simply make blobandconquer-data arch any for now. That would presumablly fix the issue for all architectures and would be minimally invasive (remember we are in freeze at the moment). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493300: blobandconquer crashes on startup on i386
If the patch doesn't work The patches author clearly stated that the patch was incomplete only dealing with word size differences not endian differences (so it will fix compatibility between i386 and amd64 but not between those architectures and say powerpc). That should be easilly fixed though. I'll rather provide the datafiles unpakked. Making it arch any is really undesirable, the fact that we are frozen does not mean we should go for quick, sub-optimal fixes. Sure, but equally it is time to keep fixes simple and unlikely to cause regressions. It seems the issue isn't as bad as my initial reading of the bugreport suggested, it seems the issue is only about a pak type format (with only a few fields involved) , not about the main game data formats. So a proper fix shouldn't be too risky. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493409: simutrans-pak64: FTBFS: Invalid image width
I have managed to fix it up so it doesn't error out but it produces different output on the two platforms. and i'm finding the code very hard to follow. The first issue was a relatively simple one. in utils/dr_rdpng.c some tweaking is required, replace the call to png_get_IHDR with //png_uint_32 is 64 bit on some architectures! png_uint_32 widthpu32,heightpu32; png_get_IHDR( png_ptr, info_ptr, widthpu32, heightpu32, bit_depth, color_type, interlace_type, NULL, NULL ); *width = widthpu32; *height = heightpu32; The second problem is that the compbination of calculations in obj_node_t::write_data and obj_node_t::write_data_at leads to negative offsets. I dunno what the correct fix is for that (I tried both replacing 4 with sizeof(obj_besch_t) and replacing sizeof(obj_besch_t) with 4) both stopped it crashing neither made it produce the same output as the i386 version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493429: 493429
tags 493429 +patch thanks change priv-PM-pcm-addPCMfloat(*pcm,512); to priv-PM-pcm()-addPCMfloat(*pcm,512); to fix this bug -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493886: please remove old binaries for libdcop3-jni, libdcop3-java-dev, libqt3-jni and libkde3-jni on alpha
package: ftp.debian.org The latest version of the kdebindings source package dropped a number of binary packages on alpha as a result of the removal of gcj from that architecture. * No java in alpha: - Do not build depend on java-gcj-compat-dev. - Remove binaries in alpha: libdcop3-jni, libdcop3-java-dev, libqt3-jni, libkde3-jni Please remove the old binary packages so that this package can transition to testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
retitle 493992 jcc FTBFS on everything except amd64 due to wrong paths.
thanks
Reading the build log carefully this doesn't look like a missing
dependency error to me (openjdk-6-jdk which depends on openjdk-6-jre
which depends on openjdk-6-jre-headless which provides the libjvm.so is
indeed included in the build-dependencies and installed by the
autobuilder). Rather it seems that the paths are wrong causing the
package to FTBFS everywhere except amd64
g++ -pthread -shared -g -O2 -g -Wall -O2
/build/buildd/jcc-1.9/./build/temp.linux-sparc-2.4/jcc/sources/jcc.o
/build/buildd/jcc-1.9/./build/temp.linux-sparc-2.4/jcc/sources/JCCEnv.o -o
/build/buildd/jcc-1.9/./build/lib.linux-sparc-2.4/libjcc.so
-L/usr/lib/jvm/java-6-openjdk/jre/lib/amd64
-L/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server
-Wl,-rpath=/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server
-ljava -Wl,-S
Notice the repeated occourance of amd64 in that line.
A patch fixing the issue is attatched.
BTW the version currently in testing is in contrib, uses the propietry
sun jdk and builds on all architectures that suns jdk is availible on.
diff -ur jcc-1.9/debian/rules jcc-1.9.new/debian/rules
--- jcc-1.9/debian/rules 2008-08-06 21:14:38.0 +
+++ jcc-1.9.new/debian/rules 2008-08-06 21:17:05.0 +
@@ -1,5 +1,16 @@
#!/usr/bin/make -f
+DEB_BUILD_ARCH_CPU ?=$(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU)
+
+#deb_build_arch_cpu gives correct path on most architectures but powerpc needs special casing
+JAVAARCH :=$(DEB_BUILD_ARCH_CPU)
+
+ifeq ($(DEB_BUILD_ARCH_CPU),powerpc)
+ JAVAARCH :=powerpc
+endif
+
+export JCC_LFLAGS :=-L/usr/lib/jvm/java-6-openjdk/jre/lib/$(JAVAARCH)::-L/usr/lib/jvm/java-6-openjdk/jre/lib/$(JAVAARCH)/server::-Wl,-rpath=/usr/lib/jvm/java-6-openjdk/jre/lib/$(JAVAARCH):/usr/lib/jvm/java-6-openjdk/jre/lib/$(JAVAARCH)/server::-ljava
+
include /usr/share/cdbs/1/rules/debhelper.mk
DEB_PYTHON_SYSTEM = pysupport
include /usr/share/cdbs/1/class/python-distutils.mk
diff -ur jcc-1.9/setup.py jcc-1.9.new/setup.py
--- jcc-1.9/setup.py 2008-08-06 21:14:38.0 +
+++ jcc-1.9.new/setup.py 2008-08-06 20:48:57.0 +
@@ -40,7 +40,7 @@
#
# Instead of editing the entries below, you may also override these
# dictionaries with JCC_INCLUDES, JCC_CFLAGS and JCC_LFLAGS environment
-# variables using os.pathsep as value separator.
+# variables using os.pathsep twice as value separator.
INCLUDES = {
'darwin': ['/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers'],
@@ -75,6 +75,7 @@
def main():
_jcc_argsep = os.environ.get('JCC_ARGSEP', os.pathsep)
+_jcc_argsep += _jcc_argsep #use a double path seperator to allow specifying an rpath with a colon in it
if 'JCC_INCLUDES' in os.environ:
_includes = os.environ['JCC_INCLUDES'].split(_jcc_argsep)
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
Jeff Breidenbach wrote: Peter, Thank you very much for the patch. It is almost right. Open JDK 1.6 has this really weird setup where one of the shared libraries is under the server subdirectory on AMD64 and under the client subdirectory under i386. (Not sure what the story is on other architectures). What libarary is that? with my patch the code seems to build on both i386 and amd64. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
The PyLucene binary has almost exactly the same problem if you are interested in looking at that one too. PyLucene seems to build fine in my i386 sid chroot using the jcc built using my patch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
Jeff Breidenbach wrote: What library is that? libjvm.so Specifically /usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so As found here: http://packages.debian.org/sid/i386/openjdk-6-jre-headless/filelist checking packages.debian.org it seems that file is in the server directory on all architectures and also in the client directory on i386 and sparc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
I'm surprised you got PyLucene to build; I wonder if it runs (there is a simple test in the PyLucene README.Debian) From my i386 chroot with jcc built with my patch and pylucene built using the jcc built with my patch and unmodified source. debian:/# python Python 2.5.2 (r252:60911, Jul 31 2008, 07:39:27) [GCC 4.3.1] on linux2 Type help, copyright, credits or license for more information. import lucene lucene.initVM(lucene.CLASSPATH) jcc.JCCEnv object at 0xf7d07240 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494296: rosegarden: Uninstallable in Sid
Rosegarden is uninstallable, at least on my Sid system. I get the following error message when running apt-get install rosegarden: The following packages have unmet dependencies. rosegarden: Depends: kdebase-bin but it is not going to be installed E: Broken packages I tried and failed to reproduce this so I suspect it was just a transiant issue (transiant uninstallability is normal in sid, it is only if it goes on for some time that it is worth a bug report). If you can still reproduce it could you try adding the packages it says won't be installed to the install command line until you get a more usefull error message out of apt? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494327: pdftk: FTBFS in lenny: gcj-4.2: libgcj.spec: No such file or directory
my test results for pdftk (which has the same version in both lenny and sid) build in sid: builds sucessfully build in lenny: FTBFS build in lenny with sids gcj-4.2, gcj-4.2-base, gij-4.2, libgcj8-1, libgcj8-1-awt, libgcj8-dev, libgcj8-jar (that is all packages from the gcj-4.2 source package that were installed were upgraded to sid's versions) : builds sucessfully. release team: are you planning to let gcj-4.2 4.2.4-3.1 into lenny (looks like the only change in sid since the freeze is a reupload to fix a version numbering screwup) or does another soloution to this bug have to be found? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494328: acl2: FTBFS in lenny: Initialization FAILED: acl2-status.txt should contain :INITIALIZED.
my test results lenny's version in lenny: (though I got a different error: FATAL ERROR: ACL2 does not yet support GCL ANSI. Please use a non-ANSI GCL. sid's version in lenny: FTBFS with Compile FAILED: file acl2-status.txt is missing. lenny's version in sid: FTBFS with Initialization FAILED: acl2-status.txt should contain :INITIALIZED. sid's version in sid: builds fine note: when asked whether I wanted to Use the work-in-progress ansi build by default? and whether I wanted to Use the profiling build by default? in my lenny chroot I picked the default answer in both cases which was yes. I was not asked those questions in my sid chroot, I dunno if this means the questions were removed or that I answered them at some time in the past. I don't have a clue what to make of theese results other than getting the impression that something really weired is happening -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494395: please remove old ia64 binaries for kaya
package: ftp.debian.org kaya dropped support for the ia64 architecture due to toolchain issues. Please remove the old ia64 binaries so the new version can migrate to testing (which is important because the new version fixes a rc bug) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494405: asterisk: build depends on libc-client2007b-dev though libc-client2007b-dev
severity 494405 normal thanks Justification: no longer builds from source experimental version of asterisk (1:1.4.21.2~dfsg-2) found in trunk for svn repo of pkg-voip doesnt build on etch as it requires libc-client2007b-dev which is not found in etch. Sarge's version builds fine in sarge, Etch's version builds fine in etch, lenny's version builds fine in lenny and sid's version builds fine in sid. Being able to easilly backport stuff is nice but not being able to certainly isn't an rc issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494496: jcc FTBFS on powerpc due to a typo in my previous patch
package: jcc version: 1.9-5 severity: important justification: FTBFS on an architecture the package has never sucessfully built on before. I made a typo in the patch I sent you ifeq ($(DEB_BUILD_ARCH_CPU),powerpc) JAVAARCH :=powerpc endif should have been ifeq ($(DEB_BUILD_ARCH_CPU),powerpc) JAVAARCH :=powerpc endif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494496: jcc FTBFS on powerpc due to a typo in my previous patch
I must be tired, I can't even get my corrections right first time :( I made a typo in the patch I sent you ifeq ($(DEB_BUILD_ARCH_CPU),powerpc) JAVAARCH :=powerpc endif should have been ifeq ($(DEB_BUILD_ARCH_CPU),powerpc) JAVAARCH :=ppc endif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494225: sugar-hulahop: FTBFS: ld: cannot find -lpyxpcom
tags 494225 +patch thanks add LDFLAGS += -L/usr/lib/xulrunner-1.9 to debian/rules (I put it just below the block of comments at the start) to make this package build. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494216: shaperd: FTBFS: packet.hpp:10:21: error: libipq.h: No such file or directory
tags 494216 +patch thanks the following patch fixes the ftbfs, I haven't tested if the resulting package actually works or not though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494216: shaperd: FTBFS: packet.hpp:10:21: error: libipq.h: No such file or directory
oops forgot to actually push the patch out to a file and attatch it to
the mail
peter green wrote:
tags 494216 +patch
thanks
the following patch fixes the ftbfs, I haven't tested if the resulting
package actually works or not though.
diff -ur shaperd-0.2.1/debian/control shaperd-0.2.1.new/debian/control
--- shaperd-0.2.1/debian/control 2008-08-14 02:16:50.0 +0100
+++ shaperd-0.2.1.new/debian/control 2008-08-14 02:16:01.0 +0100
@@ -2,7 +2,7 @@
Section: admin
Priority: optional
Maintainer: RISKO Gergely [EMAIL PROTECTED]
-Build-Depends: debhelper ( 2.0.0), iptables-dev
+Build-Depends: debhelper ( 2.0.0), iptables-dev, libnetfilter-queue-dev
Standards-Version: 3.5.8.0
Package: shaperd
diff -ur shaperd-0.2.1/src/main.cpp shaperd-0.2.1.new/src/main.cpp
--- shaperd-0.2.1/src/main.cpp 2008-08-14 02:16:50.0 +0100
+++ shaperd-0.2.1.new/src/main.cpp 2008-08-14 02:15:24.0 +0100
@@ -26,6 +26,7 @@
#ifdef WITH_IPQ
#include linux/netfilter.h
#include libipq.h
+ #include libnetfilter_queue.h
#endif //WITH_IPQ
}
@@ -638,7 +639,7 @@
goto __err_ipq_mode;
}
- kernel_sock = ipq_h-fd;
+ kernel_sock = nfq_fd(ipq_h-nfqnlh);
log_info(LL_DEBUG1, using netlink socket %d {%s:%d},
kernel_sock, __FILE__, __LINE__);
diff -ur shaperd-0.2.1/src/makefile shaperd-0.2.1.new/src/makefile
--- shaperd-0.2.1/src/makefile 2008-08-14 02:16:50.0 +0100
+++ shaperd-0.2.1.new/src/makefile 2008-08-14 02:03:51.0 +0100
@@ -9,8 +9,8 @@
objs = classifier.o bwadm.o classdef.o config.o packet.o main.o sched.o log.o
deps = $(objs:.o=.d)
libs =
-dopt = -I/usr/src/linux/include -I/usr/include/libipq
-copt = -Wall -O2 -I/usr/src/linux/include -I/usr/include/libipq
+dopt = -I/usr/src/linux/include -I/usr/include/libnetfilter_queue
+copt = -Wall -O2 -I/usr/src/linux/include -I/usr/include/libnetfilter_queue
lopt = -Wall -O2
GCC = gcc
G++ = g++
@@ -29,7 +29,7 @@
ifeq ($(with_ipq), yes)
dopt += -DWITH_IPQ
copt += -DWITH_IPQ
- libs += -lipq
+ libs += -lnetfilter_queue -lnetfilter_queue_libipq
ifneq ($(MAKECMDGOALS), clean)
-include $(deps)
endif
Bug#484695: vlc: Please switch to libdc1394-22
tags 484695 patch sid thanks fixing this seems to be as simple as just changing the build-depends. However lenny still has a libavcodec-dev that depends on libdc1394-13-dev so care should be taken to make sure that a fixed vlc doesn't make it into lenny too early. http://packages.debian.org/lenny/libdc1394-13-dev One option would be to not explicitly build depend on libdc1394-??-dev at all and just let libavcodec-dev pull it in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495313: cacao-oj6_6b11-1(sparc/unstable): FTBFS, missing build depends on zlib
Build-Depends: debhelper (= 5), autotools-dev, bzip2, m4, lsb-release, wget, zip, unzip, sharutils, gawk, pkg-config, procps, automake, autoconf, ant, g++-4.3, gcj (= 4:4.2.1) [armel ia64 m68k mips mipsel s390], ecj [armel ia64 m68k mips mipsel s390], java-gcj-compat-dev (= 1.0.76-2ubuntu3) [armel ia64 m68k mips mipsel s390], openjdk-6-jdk (= 6b11) [amd64 i386 lpia sparc], cacao-oj6-jdk [alpha powerpc], libxtst-dev, libxi-dev, libxt-dev, libxp-dev, libxaw7-dev, libcups2-dev, libasound2-dev, libfreetype6-dev, libxalan2-java, rhino, liblcms1-dev, libxinerama-dev, libffi-dev [!amd64 !i386 !lpia !sparc], libjpeg62-dev, libpng12-dev, libgif-dev, zlib1g-dev, libgtk2.0-dev, iceape-dev, fastjar (= 2:0.95-2), mauve, xvfb, xauth, xfonts-base zlib1g-dev is in that line and zlib1g-dev contains libz.so. Furthermore sparc is the only architecture where the package FTBFS with this error (though it FTBFS on most architectures for other reasons :( ) can you reproduce the issue and if so can you supply the config.log so we can see the real reason why configure is failing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489838: mm3d_1.3.7-1(sparc/unstable): configure: error: Failed to link Qt with OpenGL support.
tags 489838 +patch thanks It seems that upstream has switched to using qt4 rather than qt3 but the build-depends were not updated to match. to fix this bug change libqt3-mt-dev to libqt4-dev, libqt4-opengl-dev in the build dependencies -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495514: azureus and openjdk
package: azureus severity: serious justification: policy 3.5 There were a number of rc bugs reported about azureus not working with gij. Theese were closed with the justification that azureus could now be used with openjdk. However no packaging changes were made to reflect this. IMO the following changes should be made to the azureus package * the dependencies should be changed to reflect the JVMs that azureus actually works with. * the azureus launch script should be changed to make sure azureus actually uses a vm that it works with * the azureus-gcj package should be dropped -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495256: cacao-oj6 should not duplicate the upstream, openjdk and cacao sources
I cannot find this package anyway, Maybe a typo? cacao-oj6 is the source package name. http://packages.qa.debian.org/c/cacao-oj6.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495514: patch to make azureus use only sun based runtimes
tags 495514 +patch
thanks
patch is attatched.
note: while I have written a changlog entry explaining the changes I am
not a dd so I cannot upload the package
diff -ur azureus-3.1.1.0/debian/bin/azureus azureus-3.1.1.0.new/debian/bin/azureus
--- azureus-3.1.1.0/debian/bin/azureus 2008-08-19 00:02:34.0 +0100
+++ azureus-3.1.1.0.new/debian/bin/azureus 2008-08-18 23:50:17.0 +0100
@@ -1,5 +1,85 @@
-#!/bin/sh
-JAVA='java -Xmx1024M'
+#!/bin/bash
+JAVA=`readlink /etc/alternatives/java`
+JAVA_HOME=${JAVA_HOME:=${JAVA%/*/*/*}}
+echo $JAVA_HOME
+
+
+#we need to check the JRE exists, is sun based and is not headless
+#checking for $JAVA_HOME/jre/bin/policytool will kill all theese birds with
+#one stone
+
+ACCEPTABLE=1
+
+if [[ -e $JAVA_HOME/jre/bin/policytool ]]
+then
+ echo this jre passed the installed/sun based/not headless test
+else
+ ACCEPTABLE=0
+ echo this jre failed the installed/sun based/not headless test
+fi
+
+ARCH=`dpkg --print-installation-architecture`
+#32 bit jre's on amd64 installations will fail to load SWT
+if [[ ARCH -eq amd64 ]]
+then
+ if objdump -f $JAVA_HOME/jre/bin/java | grep elf32-i386 /dev/null
+ then
+echo this jre failed the amd64 system needs 64 bit jre for swt to load test
+ACCEPTABLE=0;
+ else
+echo this jre passed the amd64 system needs 64 bit jre for swt to load test
+ fi
+
+fi
+
+if [[ $ACCEPTABLE -eq 0 ]]
+then
+ if [[ -e /usr/lib/jvm/java-6-openjdk/jre/bin/policytool ]]
+ then
+JAVA_HOME=/usr/lib/jvm/java-6-openjdk
+ACCEPTABLE=1
+ fi
+fi
+
+if [[ $ACCEPTABLE -eq 0 ]]
+then
+ if [[ -e /usr/lib/jvm/java-6-cacao/jre/bin/policytool ]]
+ then
+JAVA_HOME=/usr/lib/jvm/java-6-cacao
+ACCEPTABLE=1
+ fi
+fi
+
+if [[ $ACCEPTABLE -eq 0 ]]
+then
+ if [[ -e /usr/lib/jvm/java-6-sun/jre/bin/policytool ]]
+ then
+JAVA_HOME=/usr/lib/jvm/java-6-sun
+ACCEPTABLE=1
+ fi
+fi
+
+if [[ $ACCEPTABLE -eq 0 ]]
+then
+ if [[ -e /usr/lib/jvm/java-1.5.0-sun/jre/bin/policytool ]]
+ then
+JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
+ACCEPTABLE=1
+ fi
+fi
+
+
+if [[ $ACCEPTABLE -eq 0 ]]
+then
+ echo no acceptable jre could be found, this should never happen unless
+ echo dependencies are broken
+ exit 1
+fi
+
+echo $JAVA_HOME
+
+export JAVA_HOME
+JAVA=$JAVA_HOME/jre/bin/java -Xmx1024M
. /usr/share/java-config/libswt-3.4-java
exec $JAVA -Djava.library.path=/usr/lib/jni:/usr/lib \
-classpath /usr/share/java/Azureus2.jar:$JARS \
diff -ur azureus-3.1.1.0/debian/changelog azureus-3.1.1.0.new/debian/changelog
--- azureus-3.1.1.0/debian/changelog 2008-08-19 00:02:34.0 +0100
+++ azureus-3.1.1.0.new/debian/changelog 2008-08-18 23:43:05.0 +0100
@@ -1,3 +1,13 @@
+azureus (3.1.1.0-3.1) unreleased; urgency=medium
+
+ * fixups to stop azureus using gcj (which it doesn't work with)
+* don't bother generating a package with useless gij native code
+* make startup script select a suitable runtime
+* change depdencies
+* Closes: 495514
+
+ -- Peter Green [EMAIL PROTECTED] Mon, 18 Aug 2008 23:33:00 -0100
+
azureus (3.1.1.0-3) unstable; urgency=medium
* Remove the four non-latin characters in DateParserRegex.java.
diff -ur azureus-3.1.1.0/debian/control azureus-3.1.1.0.new/debian/control
--- azureus-3.1.1.0/debian/control 2008-08-19 00:02:34.0 +0100
+++ azureus-3.1.1.0.new/debian/control 2008-08-18 23:32:27.0 +0100
@@ -9,8 +9,7 @@
Package: azureus
Architecture: all
-Depends: java-gcj-compat | java-virtual-machine,
- java-gcj-compat | java2-runtime, libcommons-cli-java,
+Depends: openjdk-6-jre | cacao-oj6-jre | sun-java6-jre | sun-java5-jre, binutils, libcommons-cli-java,
liblog4j1.2-java, libswt-gtk-3.4-java
Suggests: vuze, azureus-gcj
Description: BitTorrent client
@@ -21,13 +20,6 @@
access to numerous pieces of information about your torrents. Azureus
now features an embedded tracker easily set up and ready to use.
-Package: azureus-gcj
-Architecture: any
-Depends: azureus (= ${source:Version}), azureus ( ${source:Version}.1~),
- ${misc:Depends}, ${shlibs:Depends}
-Description: native binary of Azureus
- This package contains a native binary of Azureus built using GCJ.
-
Package: vuze
Architecture: all
Depends: azureus, libswt-cairo-gtk-3.4-jni, libswt-gnome-gtk-3.4-jni,
diff -ur azureus-3.1.1.0/debian/rules azureus-3.1.1.0.new/debian/rules
--- azureus-3.1.1.0/debian/rules 2008-08-19 00:02:34.0 +0100
+++ azureus-3.1.1.0.new/debian/rules 2008-08-18 22:47:48.0 +0100
@@ -40,7 +40,9 @@
include /usr/share/gcj/debian_defaults
-binary-arch: build
+binary-arch:
+
+binary-arch-old: build
dh_clean -k
dh_install -a
dh_installchangelogs -a
Bug#495514: Patch for #495514
Here's a debdiff that fixes #495514 by using openjdk-6-jdk as the default JDK, while still giving a user the option to rebuild with any JDK he likes, What JDK the package is built with is irrelevent. The problem is it doesn't work when RUN WITH gij. Indeed the dependencies on your package don't even seem to ensure that a JRE is installed at all by default. In other words your patch (unlike mine) does not actually fix the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495514: Patch for #495514
generally speaking, the JDK the package is built with *is* relevant, if only to avoid java.lang.UnsupportedClassVersionError: for instance your fix considers the JRE from sun-java5-jre to be acceptable, when it definitely is not if the package is compiled with a JDK6 (which is what will happen with the Build-Depends line you left as is). The build depends line would by default be satisfied by java-gcj-compat-dev and I have confirmed that a binary built with that DOES work with the sun-java5-jdk. It would be an issue if building with sun java6 though and It probablly does make sense to explicitly specify a classfile version. The solid fix is IMHO to ensure that you run the program with the JRE associated to the JDK you used for building. Yeah, completely ignoring the users JRE preferences is an easy fix, I dunno if that is considered acceptable or not Otherwise, you have to resort to using poorly-scalable solutions, like you did in /usr/bin/azureus by trying to hand-select what JREs are appropriate or not. I didn't just try to hand select them, I tested all the sun based jre's in debian Another, more proper solution, would be for example to Build-Depends: java5-sdk and Depends: java5-runtime, but unfortunately java-gcj-compat provides java5-runtime, which takes us back to square one. And even if it didn't provide it depending on a JRE does not provide any gaurantee that the JRE you depend on will be the JRE the user/system select as default. So if you want functionality that is not provided by every JRE you need to either lock to one JRE or use a selection script like the one I wrote (this is something that should probablly be centralised but that is something to be considered post-lenny) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492311: icedtea-gcjwebplugin should be moved to main ASAP
The maintainer for icedtea-gcjwebplugin argued for this being contrib with wrong reasoning. Where did he do that? I don't see any posts from the maintainer in the bug report log (even the setting of pending wasn't done by someone on the current maintainers list though they may be someone in the team. As for the changelog no reason was given there for the move to contrib. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495770: marble has rpath to insecure location (/tmp/buildd/marble-0.6+svn837399/debian/tmp/usr/)
#introduces a security hole allowing access to the accounts of users who use the package severity 495770 grave tags 495770 +patch thanks I have prepared a patch to debian/rules which fixes the issue by removing the rpath from all binaries in that directory. there is also some code in debian/rules which seems to turn lintain results from the previous build into lintain overrides. This means that afacit if someone builds a package more than once (as is quite normal) then every lintain issue will get overridden! I have diabled this code in my diff. mailto:[EMAIL PROTECTED] Only in marble-0.6+svn837399/data/mwdbii: PISLAND.PNT.orig Only in marble-0.6+svn837399/data/mwdbii: PLAKE.PNT.orig diff -ur marble-0.6+svn837399/debian/rules marble-0.6+svn837399.new/debian/rules --- marble-0.6+svn837399/debian/rules 2008-08-20 20:45:30.0 + +++ marble-0.6+svn837399.new/debian/rules 2008-08-20 20:27:15.0 + @@ -68,11 +68,14 @@ common-install-prehook-arch:: install -m 644 $(CURDIR)/debian/globe.xpm $(CURDIR)/debian/marble/usr/share/pixmaps/globe.xpm -common-install-arch:: - install -D -m 644 $(CURDIR)/debian/marble.lintian $(CURDIR)/debian/marble/usr/share/lintian/overrides/marble +#common-install-arch:: +# install -D -m 644 $(CURDIR)/debian/marble.lintian $(CURDIR)/debian/marble/usr/share/lintian/overrides/marble -common-install-indep:: - install -D -m 644 $(CURDIR)/debian/marble-data.lintian $(CURDIR)/debian/marble-data/usr/share/lintian/overrides/marble-data +#common-install-indep:: +# install -D -m 644 $(CURDIR)/debian/marble-data.lintian $(CURDIR)/debian/marble-data/usr/share/lintian/overrides/marble-data common-binary-post-install-indep:: rm -f $(CURDIR)/debian/marble-data/usr/share/marble/data/LICENSE.txt + +common-binary-post-install-arch:: + chrpath -d debian/marble/usr/lib/marble/plugins/*
Bug#495785: attal has rpath to insecure location (.:/usr/lib/attal)
tags 495785 +patch
thanks
It seems when adapting the package to work under fhs rather than from a
single directory a new rpath was added but the old one
was never removed. I have attatched a new version of 05_rpath.diff that
does so. Just replace the old one in debian/patches.
Index: attal-1.0~rc1+cvs20080318/config.pro
===
--- attal-1.0~rc1+cvs20080318.orig/config.pro 2008-03-01 15:49:24.0 +
+++ attal-1.0~rc1+cvs20080318/config.pro 2008-08-20 21:45:47.0 +
@@ -22,6 +22,7 @@
CONFIG += qt
CONFIG += warn_on
#CONFIG += staticlib
+ LIBS += -Wl,-rpath,/usr/lib/attal
!isEmpty( ATT_CROSS_COMPILE ) {
CONFIG += crosslinwin
Index: attal-1.0~rc1+cvs20080318/ai/ai.pro
===
--- attal-1.0~rc1+cvs20080318.orig/ai/ai.pro 2008-08-20 21:46:44.0 +
+++ attal-1.0~rc1+cvs20080318/ai/ai.pro 2008-08-20 21:47:02.0 +
@@ -34,9 +34,9 @@
}
QT += xml network
-unix:!macx {
- QMAKE_LFLAGS += -Wl,-rpath,.
-}
+#unix:!macx {
+# QMAKE_LFLAGS += -Wl,-rpath,.
+#}
unix {
target.path = $${ATT_PREFIX}/bin/
Index: attal-1.0~rc1+cvs20080318/campaignEditor/campaignEditor.pro
===
--- attal-1.0~rc1+cvs20080318.orig/campaignEditor/campaignEditor.pro 2008-08-20 21:47:12.0 +
+++ attal-1.0~rc1+cvs20080318/campaignEditor/campaignEditor.pro 2008-08-20 21:47:29.0 +
@@ -38,9 +38,9 @@
TRANSLATIONS += ../i18n/ru/campaign_editor_ru.ts
TRANSLATIONS += ../i18n/it/campaign_editor_it.ts
-unix:!macx {
- QMAKE_LFLAGS += -Wl,-rpath,.
-}
+#unix:!macx {
+# QMAKE_LFLAGS += -Wl,-rpath,.
+#}
unix {
target.path = $${ATT_PREFIX}/bin/
Index: attal-1.0~rc1+cvs20080318/client/client.pro
===
--- attal-1.0~rc1+cvs20080318.orig/client/client.pro 2008-08-20 21:48:12.0 +
+++ attal-1.0~rc1+cvs20080318/client/client.pro 2008-08-20 21:48:26.0 +
@@ -47,9 +47,9 @@
TARGET = attal-client
-unix:!macx {
- QMAKE_LFLAGS += -Wl,-rpath,.
-}
+#unix:!macx {
+# QMAKE_LFLAGS += -Wl,-rpath,.
+#}
unix {
target.path = $${ATT_PREFIX}/bin/
Index: attal-1.0~rc1+cvs20080318/scenarioEditor/scenarioEditor.pro
===
--- attal-1.0~rc1+cvs20080318.orig/scenarioEditor/scenarioEditor.pro 2008-08-20 21:48:41.0 +
+++ attal-1.0~rc1+cvs20080318/scenarioEditor/scenarioEditor.pro 2008-08-20 21:48:59.0 +
@@ -72,9 +72,9 @@
TRANSLATIONS += ../i18n/ru/scenario_editor_ru.ts
TRANSLATIONS += ../i18n/it/scenario_editor_it.ts
-unix:!macx {
- QMAKE_LFLAGS += -Wl,-rpath,.
-}
+#unix:!macx {
+# QMAKE_LFLAGS += -Wl,-rpath,.
+#}
unix {
target.path = $${ATT_PREFIX}/bin/
Index: attal-1.0~rc1+cvs20080318/server/server.pro
===
--- attal-1.0~rc1+cvs20080318.orig/server/server.pro 2008-08-20 21:49:09.0 +
+++ attal-1.0~rc1+cvs20080318/server/server.pro 2008-08-20 21:49:21.0 +
@@ -40,9 +40,9 @@
TARGET = attal-server
-unix:!macx {
- QMAKE_LFLAGS += -Wl,-rpath,.
-}
+#unix:!macx {
+# QMAKE_LFLAGS += -Wl,-rpath,.
+#}
unix {
target.path = $${ATT_PREFIX}/bin/
Index: attal-1.0~rc1+cvs20080318/themeEditor/themeEditor.pro
===
--- attal-1.0~rc1+cvs20080318.orig/themeEditor/themeEditor.pro 2008-08-20 21:49:29.0 +
+++ attal-1.0~rc1+cvs20080318/themeEditor/themeEditor.pro 2008-08-20 21:49:50.0 +
@@ -81,9 +81,9 @@
TARGET = attal-theme-editor
-unix:!macx {
- QMAKE_LFLAGS += -Wl,-rpath,.
-}
+#unix:!macx {
+# QMAKE_LFLAGS += -Wl,-rpath,.
+#}
unix {
target.path = $${ATT_PREFIX}/bin/
Bug#495770: marble has rpath to insecure location (/tmp/buildd/marble-0.6+svn837399/debian/tmp/usr/)
isn't building with -DCMAKE_SKIP_RPATH=ON enough to fix it without using chrpath ? adding that to the CMAKE= line in debian/rules does indeed deal with the rpath issue -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495514: Patch for #495514
Thanks for your work. I'm away on my honeymoon though, and so won't be able to help out. If, amongst yourslves, you're able to arrive at a consensus as to the best solution, please NMU as necessary. While I preffer my soloution to sebastiens his current nmu to delayed will solve the main bug. Neither soloution is ideal (mine involves a lot of hardcoding, shauns takes away choice of JRE) but I think the ideal soloution will have to wait until post lenny. Long term I think we need a standard tool provided by one of the core java packages that selects a JRE/JDK based on a set of requirements (requirements may include things like being based on the sun code, supporting a certain version of the java standard/classfile format, being native to the current debian architecture, supporting a gui etc) using the users preffered JRE if it meets those requirements and a set of virtual packages to go with them to allow packages to depend on having a JRE that meets thier requirements). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498774: Package not installable on sid
I just tried to reproduce this in both my normal sid amd64 chroot and a sid amd64 pbuilder and could not do so. Can you still reproduce the issue on your system? Is the system suffering the issue the same one you reported the bug from? if not what architecture is the system suffering the issue? What does apt-get install reportbug-ng python-qt4 return? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499346: homepage is IMO inappropriate for release
package: iceweasel The homepage on my iceweasel install which was set by the package and never changed manully used to be about: which was IMO a reasonable choice. At some stage it changed to http://www.mozilla.org/projects/granparadiso/; which says Note: The Gran Paradiso Alpha build you are using is NOT A FINAL VERSION of Firefox, it has been made available for testing purposes only, with no end-user support. If that sounds scary, you'd probably be better off with the latest version of Firefox that you can download here. If this information is incorrect for debian users (as I suspect it is) then the default homepage needs to be changed so our browser does not misinform users. I really hope the information is not correct. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498216: ffmpeg, mplayer (mipsel/loongson2f) stops with the, error message Segmentation fault. and fix patch
Should a bug in a kernel/architecture that is not even supported by Debian really be considered RC? Most Probably not. However I currently suspect this bug to be a duplicate Bug #498397. In that case, we would indeed have RC bug that would affect both mips and mispel. This patch was one of the first things I tried when trying to deal with the bug in vlc. It didn't help. A possible workarround for the bug that impacts vlc may be to disable the cleanup on unload code completely on mips (I haven't got arround to testing this yet though). It would mean a memory leak but only if an app unloads libavcodec at a point where the app isn't dying anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484190: gem and libquicktime
A NMU of gem was made by Alexander Reichle-Schmehl [EMAIL PROTECTED] mailto:tolimar%40debian.org to fix the rc bugs 421560, 484190 and 485798 and was unblocked by he. Unfortunately it has picked up a depedency on a new upstream version of libquicktime which is blocking it's transition to testing. IMO the most reasonable soloution would be for someone (I can't do it because I'm not a dd) to reupload the NMU to testing proposed-updates. Does the release team agree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400768: apt-0.7.15~exp2: Improvement but only for borderline cases.
I believe this should not be RC for Lenny. The bug only triggers for people using multiple releases; so anyone hitting this bug should be able to get an updated version from unstable or squeeze-testing without needing it in Lenny. It could also cause issues for people upgrading from lenny oldstable to squeeze stable. Especially if they don't delete the lenny DVDs from thier sources.list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500052: python-xlrd: Cannot install
Did you report this from the system you had the problem on. If so then the following line of your bug report explains your issue and it is not a bug. APT policy: (700, 'stable'), (500, 'testing') python-xlrd is not in stable so apt picks the testing version but then it's dependencies can't be satisfied from stable so it gives an error. If not then please post the output of the following commands apt-cache policy python-central apt-get install python-xlrd python-central -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500325: xorp: FTBFS: Not using -fPIC to generate shared lib.
tags 500325 +patch thanks It seems you have a mix of things you want to build shared and static, but that doesn't work. It looks to me like the package builds a static library and then tries to use that static library to form part of a shared library. Unfortunately that static library is not getting built PIC Since afaict no static libraries are included in the package the easiest soloution seems to be to force the entire package to be built with -fPIC . to do this replace the following line in debian/rules CFLAGS = -Wall -g with CFLAGS = -Wall -g -fPIC CXXFLAGS += -fPIC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491385: fix for 491385
tags 491385 +patch thanks replace xlibs-data with xbitmaps in the build dependencies to fix this bug -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479751: azureus: Requires Sun Java
Since openjdk is now available in main, wouldn't that be the best solution? It would if it was in lenny but unfortunately openjdk was delayed hugely by license issues :(. Now we have a situation where afiact openjdk will only make it into lenny if one of the following happens. *The rc bug (491362) that is open against openjdk gets downgraded (I beleive it should be downgraded but as a non-dd I don't belive it is my place to downgrade a bug based on an unclear bit of the rc policy) and openjdk slots in just before the freeze (btw is there any actual date set for that or is it just sometime next week *The rc bug is fixed and the release team makes a freeze exception or an urgent hint to get openjdk in before the freeze *the freeze is delayed ccing debian-release to get thier opinion on what the chances are for openjdk making it into lenny. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488170: inkscape FTBFS bugs
forcemerge 488170 489083 thanks 489083 is a dupe of 488170 Some upstream discussion can be found at at http://www.nabble.com/Poppler-0.8.3-change-to-GfxFont-td17806656.html . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491510: kdebindings build-depends on java-gcj-compat-dev on alpah which is not availible
package: kdebindings version: 4:3.5.9-1 severity serious The package depends on java-gcj-compat-dev on a number of platforms including alpha, but that package is no longer available on alpha making kdebindings ftbfs. I don't know if it is safe to just remove it from the list of architectures for that build-dependency or if more work is needed. I do not have any alpha box myself. This affects both the version in lenny and the version in sid. As well as being rc in itself this is preventing the transision of the fix for 484191 to testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492084: atitvout: should this package be removed?
BTW, would it be a good idea to package lrmi appart ? In the short term IMO no. The library freeze is already in place and the full freeze is imminent. So if you want to see the package in lenny you don't want to be making major structural changes right now. In the long term IMO it depends on whether the library is used elsewhere in debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490025: this affects the version in testing too
It seems this package has never been built successfully by any buildd. The version in testing does not build any architecture specific binaries (which are not built on buildds). Given that right now azureus doesn't work with gcj anyway maybe the package should go back to doing that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497683: fix for 497683
tags 497683 +patch thanks doing as the error message suggests and adding texlive-fonts-recommended to the build-dependencies will make this package build. BTW this bug also affects sid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497683: fai: FTBFS in lenny: debiandoc2latexpdf: one or, more used LaTeX typesetting styles not found
As far as I know this definitely is a lenny issue as well. I'll try to build the FAI package in a minimalist chroot this evening, unless someone else manages to do so earlier (appreciated :-) ). I tested this in my normal (pretty dirty) lenny and sid i386 chroots and in a clean sid amd64 pbuiler. In all cases it failed to build if texlive-fonts-extra was not installed and built fine if it was installed. btw lucas your bugreport contradicts itself, the bug title and the main bulk of the bug report talks about a FTBFS in lenny but then the about the archive rebuild section says it was done in a sid chroot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497689: opencv: FTBFS in lenny: Unsatisfiable build-dependency: libavcodec-dev: Depends: libdc1394-22-dev
tags 497689 +patch thanks If the build-depedencies are overridden opencv builds succesfully with libdc1294-13-dev missing. So the bug can be fixed by either changing the build dependency to the 22 version or removing it completely and letting libavcodec-dev pull it in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497688: kino: FTBFS in lenny: Unsatisfiable build-dependency:, libavcodec-dev: Depends: libdc1394-22-dev
tags 497688 +patch thanks If the build-depedencies are overridden kino builds succesfully with libdc1294-13-dev missing. So the bug can be fixed by either changing the build dependency to the 22 version or removing it completely and letting libavcodec-dev pull it in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497998: trying to install debian armel in qemu-system-arm fails to detect network
package: installation-reports Package: installation-reports Boot method: kernel and initrd passed to qemu on command line Image version: daily build downloaded on sat 6 sep 2008 from http://people.debian.org/~joeyh/d-i/armel/images/daily/versatile/netboot/ Date: sat 6 sep 2008 Machine: qemu-system-arm Processor: whatever qemu-system-arm emulates when using -M versatilepb Memory: whatever qemu-system-arm uses by default Partitions: blank virtual hard disk just created with qemu-img Output of lspci -knn (or lspci -nn): Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: D-I booted successfully but failed to detect network, since I was using a netboot image I could not proceed any further with the installation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498053: fslview ftbfs on arm due to a segfault in libQVTKWidgetPlugin.so which is called into from uic-qt3
package: libvtk5-qt3 severity: serious justification: causes another package to FTBFS fslview fails to build on arm with a segfault in libQVTKWidgetPlugin.so which is called into from uic-qt3 a backtrace of this segfault is below. #0 0x40e3b010 in ucm_instantiate () from /usr/lib/qt3/plugins/designer/libQVTKWidgetPlugin.so #1 0x404f2198 in QComLibrary::createInstanceInternal (this=0x68000) at tools/qcomlibrary.cpp:504 #2 0x404f2668 in QComLibrary::queryInterface (this=0x68000, [EMAIL PROTECTED], iface=0xbeba1014) at tools/qcomlibrary.cpp:526 #3 0x40507df0 in QGPluginManager::addLibrary (this=0x0, lib=0x68000) at tools/qgpluginmanager.cpp:465 #4 0x405090a0 in QGPluginManager::library (this=0x68058, [EMAIL PROTECTED]) at tools/qgpluginmanager.cpp:391 #5 0x4050999c in QGPluginManager::queryUnknownInterface (this=0x40e3aff8, [EMAIL PROTECTED], iface=0x0) at tools/qgpluginmanager.cpp:546 #6 0x00039d94 in Uic::createObjectImpl (this=0xbeba2984, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../../../include/private/qpluginmanager_p.h:70 #7 0x000171dc in Uic::createLayoutImpl (this=0xbeba2984, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at uic.cpp:858 #8 0x00038048 in Uic::createObjectImpl (this=0xbeba2984, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at object.cpp:109 #9 0x000383ac in Uic::createObjectImpl (this=0xbeba2984, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at object.cpp:141 #10 0x000171dc in Uic::createLayoutImpl (this=0xbeba2984, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at uic.cpp:858 #11 0x00038048 in Uic::createObjectImpl (this=0xbeba2984, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at object.cpp:109 #12 0x0002e27c in Uic::createFormImpl (this=0x4b4dc, [EMAIL PROTECTED]) at form.cpp:1071 #13 0x00012bc8 in Uic (this=0xbeba2984, fn=value optimized out, outputFn=value optimized out, outStream=value optimized out, [EMAIL PROTECTED], decl=84, subcl=248, [EMAIL PROTECTED], [EMAIL PROTECTED], omitForwardDecls=value optimized out) at uic.cpp:211 #14 0xf4fc in main (argc=6, argv=value optimized out) at main.cpp:346 I am currently checking to see if this happens with a self built vtk, assuming it does I will then look for fixes/workarrounds (disabling optimisation will likely be the first thing I will try). Unfortunately vtk takes agest to build under qemu-system-arm :(. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498053: Acknowledgement (fslview ftbfs on arm due to a segfault in libQVTKWidgetPlugin.so which is called into from uic-qt3)
I hereby give up on trying to find a fix/workarround to this bug, building the package with qemu-system-arm on my hardware is just impractically slow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498390: gdb refuses to load freshly built vlc binary on mips
package: gdb version: 6.8-3 severity: important I have been trying to track down the build failure of vlc on mips. The build fails with a segmentation fault when doing a test run of the newly built vlc binary. I tried to use gdb to get a backtrace of the problem. Unfortunately gdb refuses to load the freshly built vlc binary. The binary does appear to be a valid executable as I get some output from it before it segfaults. debian-mips:~/vlc-0.8.6.h# gdb --args ./vlc --reset-plugins-cache -l -I rc vlc:quit GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as mips-linux-gnu... /root/vlc-0.8.6.h/vlc: not in executable format: File format not recognized (gdb) quite Undefined command: quite. Try help. (gdb) quit debian-mips:~/vlc-0.8.6.h# ./vlc --reset-plugins-cache -l -I rc vlc:quit VLC media player 0.8.6h Janus starting VLC root wrapper... using UID 0 (root) *** * Running VLC as root is discouraged. * *** It is potentially dangerous, and might not even work properly. main main program help Help options mux_tsTS muxer (libdvbpsi) theoraTheora video decoder theoraTheora video packetizer theoraTheora video encoder Segmentation fault debian-mips:~/vlc-0.8.6.h# -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
