Bug#799520: tellico: FTBFS: Missing Build-Depends on libsoprano-dev
reassign 799520 kdepimlibs5-dev
thanks
Hi, Chris,
On 19/09/15 21:46, Chris Lamb wrote:
> Source: tellico
> Version: 2.3.9+dfsg.1-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> tellico fails to build from source due to missing Build-Depends on
> libsoprano-dev. This was previously pulled-in via a transitive
> relationship.
>
Actually, Tellico does not have a single reference to soprano anywhere.
The attempt to find Soprano link to libsoprano.so are only due to the
FindNepomuk.cmake file trying to pull it in.
I don't believe it's the correct approach for tellico to have
build-depends for indirect dependencies, therefore I'm reassigning this
bug to kdelibs5-dev. As the latter source package control file mentions
'${sameVersionDep:libsoprano-dev:libnepomuk4}' in its depends, it looks
to me like something actually went wrong when building kde4libs and the
dependency was not actually added.
Thanks,
Regis
Bug#650653: NMU 3.6.0dfsg-2.1
Hi,
As tulip has FTBFS on all buildds for over 220 days, and the remaining
arch is not installable either, I'm about to upload a NMU fixing the
build, which includes also fixes for the FTBFS with GCC 4.7 (#667401),
as well as updating the libpng-dev build-dependency (#662526).
Please find the diff to -2.1 attached.
Thanks,
Regis
diff -Nru tulip-3.6.0dfsg/debian/changelog tulip-3.6.0dfsg/debian/changelog
--- tulip-3.6.0dfsg/debian/changelog 2011-09-09 22:58:34.0 +0200
+++ tulip-3.6.0dfsg/debian/changelog 2012-04-23 22:52:44.0 +0200
@@ -1,3 +1,13 @@
+tulip (3.6.0dfsg-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix debian/rules, so the package compiles on the buildds. Closes: #650653.
+ * Add gcc4.7_ftbfs patch to fix FTBFS with GCC 4.7. Closes: #667401.
+ * Update Build-Depends on libpng-dev. Closes: #662526.
+ * Bump debhelper Build-Depends to = 9, as recommended by lintian.
+
+ -- Regis Boudin re...@debian.org Mon, 23 Apr 2012 22:52:11 +0200
+
tulip (3.6.0dfsg-2) unstable; urgency=low
* Don't build docs for tulip-doc from build-arch, move java packages,
diff -Nru tulip-3.6.0dfsg/debian/control tulip-3.6.0dfsg/debian/control
--- tulip-3.6.0dfsg/debian/control 2011-09-05 22:43:32.0 +0200
+++ tulip-3.6.0dfsg/debian/control 2012-04-23 22:53:57.0 +0200
@@ -2,7 +2,7 @@
Section: graphics
Priority: optional
Maintainer: Yann Dirson dir...@debian.org
-Build-Depends: debhelper ( 8), cmake, libqt4-dev, qt4-dev-tools, freeglut3-dev, docbook-to-man, libgl1-mesa-dev | libgl-dev, dh-buildinfo, libfreetype6-dev, libxml2-dev, libgle3-dev, libxml2-utils, graphviz, libjpeg-dev, libpng12-dev, libftgl-dev, libglew1.5-dev, libqt4-opengl-dev
+Build-Depends: debhelper (= 9), cmake, libqt4-dev, qt4-dev-tools, freeglut3-dev, docbook-to-man, libgl1-mesa-dev | libgl-dev, dh-buildinfo, libfreetype6-dev, libxml2-dev, libgle3-dev, libxml2-utils, graphviz, libjpeg-dev, libpng-dev, libftgl-dev, libglew1.5-dev, libqt4-opengl-dev
Build-Depends-Indep: default-jre-headless, libsaxon-java, libxml-commons-resolver1.1-java, docbook-xsl, doxygen
Homepage: http://tulip-software.org/
Standards-Version: 3.9.1
diff -Nru tulip-3.6.0dfsg/debian/patches/gcc4.7_ftbfs tulip-3.6.0dfsg/debian/patches/gcc4.7_ftbfs
--- tulip-3.6.0dfsg/debian/patches/gcc4.7_ftbfs 1970-01-01 01:00:00.0 +0100
+++ tulip-3.6.0dfsg/debian/patches/gcc4.7_ftbfs 2012-04-23 21:27:50.0 +0200
@@ -0,0 +1,15 @@
+Description: Fix FTBFS with GCC 4.7
+ Add a missing include in the headers.
+Author: Regis Boudin re...@debian.org
+
+--- tulip-3.6.0dfsg.orig/library/tulip/include/tulip/SimpleVector.h
tulip-3.6.0dfsg/library/tulip/include/tulip/SimpleVector.h
+@@ -21,6 +21,8 @@
+ #ifndef _SIMPLE_VECTOR_H_
+ #define _SIMPLE_VECTOR_H_
+
++#include cstdlib
++
+ namespace tlp {
+
+ // SimpleVector
diff -Nru tulip-3.6.0dfsg/debian/patches/series tulip-3.6.0dfsg/debian/patches/series
--- tulip-3.6.0dfsg/debian/patches/series 2011-09-09 22:57:53.0 +0200
+++ tulip-3.6.0dfsg/debian/patches/series 2012-04-23 21:26:37.0 +0200
@@ -6,3 +6,4 @@
0006-Use-system-FTGL-not-the-one-shipped-in-thirtparty.patch
0007-Disable-python-binding.patch
0008-Use-Debian-packaged-jars.patch
+gcc4.7_ftbfs
diff -Nru tulip-3.6.0dfsg/debian/rules tulip-3.6.0dfsg/debian/rules
--- tulip-3.6.0dfsg/debian/rules 2011-09-09 23:08:06.0 +0200
+++ tulip-3.6.0dfsg/debian/rules 2012-04-23 19:32:20.0 +0200
@@ -7,26 +7,23 @@
override_dh_auto_configure:
dh_auto_configure -- -DCMAKE_SKIP_RPATH:BOOL=YES
-build-arch:
- dh $@ --parallel
+override_dh_auto_build-arch:
+ dh_auto_build -a --parallel
docbook-to-man debian/tulip.sgml debian/tulip.1
-build-indep:
- #dh $@
+override_dh_auto_build-indep:
+ dh_auto_build -i
$(MAKE) -C obj-* doc
-install-indep: build-indep
- dh_prep -i
+override_dh_auto_install-indep:
+ dh_auto_install -i -- -C docs
mkdir -p debian/tmp/usr/share/doc/tulip-doc
set -e; for d in common userHandbook developerHandbook doxygen; do \
cp -a obj-*/docs/$$d debian/tmp/usr/share/doc/tulip-doc/ ;\
done
- dh_auto_install -- -C docs
- dh $@
-install-arch: build-arch
- dh_prep -a
+override_dh_auto_install-arch:
+ dh_auto_install -a
install -D debian/tulip.1 debian/tmp/usr/share/man/man1/tulip.1
- dh $@
override_dh_install:
dh_install --fail-missing
@@ -36,4 +33,3 @@
rm -f debian/tulip.1
rm -rf docs/doxygen/xml
-binary: binary-arch binary-indep ;
Bug#639559: Looking into it
Hi, thanks for the report, I'm looking into the issue, hopefully will get it fixed soon. Regis -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634292: guile-gnome-platform FTBFS
Hi, I believe I found the issue, which is the forced -DGTK_DISABLE_DEPRECATED flag in libgnomecanvas/gnome/gw/Makefile.am, and that the libgnomeui headers don't like. I have a patch fixing it (using $(GTK_DEPRECATED_CFLAGS) instead, I'll upload a NMU later today unless someone advises against it, and probably include Colin's patch as well to fix the test suite. Regis -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604815: Bug only affects squeeze
tag 604815 squeeze thanks dssi-host-jack is now built on kfreebsd* and available in wheezy, which means only squeeze is affected, so tagging this bug accordingly. Thanks, Regis -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639560: symbol changes
Hi, I made the upload, so I guess I should comment on this. On Sun, 2011-08-28 at 15:39 +0200, Jakub Wilk wrote: * Philipp Kern pk...@debian.org, 2011-08-28, 10:52: The package FTBFS'es on mips, powerpc, s390, sparc and the inofficial ports s390x and powerpcspe because of changes in the symbol set wrt the symbols file: Hmm, symbols file was added in 0.7-5, even though it isn't mentioned in the changelog. Yep, sorry, forgot to add that one to the changelog... - spifhash_jenkinsLE@Base 0.7 +#MISSING: 0.7-5# spifhash_jenkinsLE@Base 0.7 Looking at the source code spifhash_jenkinsLE is only defined on little-endian systems. Yes. + spiftool_regexp_match@Base 0.7-5 + spiftool_regexp_match_r@Base 0.7-5 These two OTOH are defined everywhere and I don't understand why they weren't included in the symbols file. Even lintian loudly complains: E: libast2: symbols-file-contains-current-version-with-debian-revision on symbol spiftool_regexp_match@Base and 1 others Except lintian didn't complain at all when I built it in a freshly updated chroot. These symbols are actually conditional on the presence of some header (regex.h) from libc6-dev, so I guess my build might have happened in a time window when there were some multi-arch related header problems. Anyway, I'll fix that with a new upload today. Regis -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622047: tellico: FTBFS: /build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/src/barcode/barcode_v4l.h:34:28: fatal error: linux/videodev.h: No such file or directory
tags 622047 pending thanks Hi, Thanks for the report. The bug is known and fixed in the upstream svn so I plan to make an upload soon. Regis On Sat, 2011-04-09 at 14:17 +0200, Lucas Nussbaum wrote: Source: tellico Version: 2.2-5 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20110408 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: make[3]: Entering directory `/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild' /usr/bin/cmake -E cmake_progress_report /build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild/CMakeFiles [ 75%] Building CXX object src/barcode/CMakeFiles/barcode.dir/barcode_automoc.o cd /build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild/src/barcode /usr/bin/c++ -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DYAZ_POSIX_THREADS=1 -DYAZ_HAVE_XML2=1 -DYAZ_HAVE_XSLT=1 -DYAZ_HAVE_EXSLT=1 -DQT_STL -DQT_NO_CAST_FROM_ASCII -g -O2 -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -Wnon-virtual-dtor -Wno-long-long -Wextra -fno-check-new -Woverloaded-virtual -DNDEBUG -DQT_NO_DEBUG -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild/src/barcode -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/src/barcode -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/src/core -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/src/3rdparty -I/usr/include/poppler/qt4 -I/usr/include/exempi-2.0 -I/usr/include/KDE -I/usr/include/qt4/phonon -I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtScriptTools -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtHelp -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtDBus -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt -I/usr/share/qt4/mkspecs/default -I/usr/include/qt4 -I/usr/include/libxml2 -I/usr/include/taglib -I/usr/include/poppler/qt4 -I/usr/include/poppler -I/usr/include/exempi-2.0 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/taglib -I/usr/include/libxml2 -o CMakeFiles/barcode.dir/barcode_automoc.o -c /build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild/src/barcode/barcode_automoc.cpp /usr/bin/cmake -E cmake_progress_report /build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild/CMakeFiles [ 75%] Building CXX object src/barcode/CMakeFiles/barcode.dir/barcode.o cd /build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild/src/barcode /usr/bin/c++ -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DYAZ_POSIX_THREADS=1 -DYAZ_HAVE_XML2=1 -DYAZ_HAVE_XSLT=1 -DYAZ_HAVE_EXSLT=1 -DQT_STL -DQT_NO_CAST_FROM_ASCII -g -O2 -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -Wnon-virtual-dtor -Wno-long-long -Wextra -fno-check-new -Woverloaded-virtual -DNDEBUG -DQT_NO_DEBUG -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild/src/barcode -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/src/barcode -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/builds/debbuild -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/src/core -I/build/user-tellico_2.2-5-amd64-dJdH2R/tellico-2.2/src/3rdparty -I/usr/include/poppler/qt4 -I/usr/include/exempi-2.0 -I/usr/include/KDE -I/usr/include/qt4/phonon -I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtScriptTools -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtHelp -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtDBus -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt -I/usr/share/qt4/mkspecs/default -I/usr/include/qt4 -I/usr/include/libxml2 -I/usr/include/taglib -I/usr/include/poppler/qt4 -I/usr/include/poppler -I/usr/include/exempi-2.0 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/taglib -I/usr/include/libxml2 -o CMakeFiles/barcode.dir/barcode.o -c
Bug#582179: FTBFS: missing build-dependency on cmake
Hi Felix, Thank you very much for the pointer. I'm about to go to bed very soon, but I'll make a new upload to fix that tomorrow. Regis On Tue, 2010-05-18 at 23:47 +0200, Felix Geyer wrote: Package: tellico Version: 2.2-3 Justification: ftbfs Severity: serious tellico FTBFS as kdelib5-dev dropped the dependency on cmake and tellico doesn't build-depend on cmake. Build log: cd builds/debbuild \ cmake /tmp/buildd/tellico-2.2 \ -DCMAKE_BUILD_TYPE=Debian -DKDE4_BUILD_TESTS=false -DKDE_DISTRIBUTION_TEXT=Debian packages -DCMAKE_SKIP_RPATH:BOOL=OFF -DKDE4_USE_ALWAYS_FULL_RPATH=false -DCONFIG_INSTALL_DIR=/usr/share/kde4/config -DDATA_INSTALL_DIR=/usr/share/kde4/apps -DHTML_INSTALL_DIR=/usr/share/doc/kde4/HTML -DKCFG_INSTALL_DIR=/usr/share/kde4/config.kcfg -DLIB_INSTALL_DIR=/usr/lib -DSYSCONF_INSTALL_DIR=/etc -DLIBKDEINIT_INSTALL_DIR:PATH=/usr/lib/kde4/libkdeinit -DENABLE_LIBKDEINIT_RUNPATH:BOOL=ON \ -DCMAKE_SHARED_LINKER_FLAGS=-Wl,--no-undefined -Wl,--as-needed -DCMAKE_MODULE_LINKER_FLAGS=-Wl,--no-undefined -Wl,--as-needed -DCMAKE_EXE_LINKER_FLAGS=-Wl,--no-undefined -Wl,--as-needed \ -DENABLE_WEBCAM=true \ -DCMAKE_INSTALL_PREFIX=/usr /bin/sh: cmake: not found make: *** [builds/debbuild] Error 127 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522240: CVE-2009-1209: Various security issues
On Wed, 2009-04-01 at 23:30 +0200, Moritz Muehlenhoff wrote: Package: amaya Severity: grave Tags: security CVE-2009-1209: Stack-based buffer overflow in W3C Amaya Web Browser 11.1 allows remote attackers to execute arbitrary code via a script tag with a long defer attribute. And that's two more... I suppose removing amaya from unstable would be the most elegant fix here. Sadly, as maintainer, I have to agree at this point. The Amaya source code is such a mess, significant portions of it deserve a complete rewrite. So let's remove it. Regis On Wed, 2009-04-01 at 23:30 +0200, Moritz Muehlenhoff wrote: Package: amaya Severity: grave Tags: security CVE-2009-1209: Stack-based buffer overflow in W3C Amaya Web Browser 11.1 allows remote attackers to execute arbitrary code via a script tag with a long defer attribute. And that's two more... I suppose removing amaya from unstable would be the most elegant fix here. Sadly, as maintainer, I have to agree at this point. The Amaya source code is such a mess, some sections deserve a complete rewrite. So let's remove it. Regis
Bug#518080: amaya: crashes on start-up: Gtk-CRITICAL assertion failed
Hi, Thanks for the report. I'm extremely busy at the moment, sorry for the delay. The Gtk-CRITICAL message doesn't actually trigger the crash, it shows up at every start (I should add a patch for that). So overall that's another crash with no explaination... Regis On Tue, March 3, 2009 23:17, Dimitri Chausson wrote: Package: amaya Version: 10.1~pre4+dfsg.0-2 Severity: grave Justification: renders package unusable Starting amaya from the shell, I only see the gui for a very short time and the following message is displayed: (amaya_bin:5618): Gtk-CRITICAL **: gtk_widget_set_colormap: assertion `!GTK_WIDGET_REALIZED (widget)' failed The program exits with return code 1. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.28.1 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages amaya depends on: ii amaya-data10.1~pre4+dfsg.0-2 Web Browser, HTML Editor and Testb ii libc6 2.7-18 GNU C Library: Shared libraries ii libexpat1 2.0.1-4XML parsing C library - runtime li ii libfreetype6 2.3.7-2FreeType 2 font engine, shared lib ii libgcc1 1:4.3.3-3 GCC support library ii libgl1-mesa-glx [libg 7.0.3-7A free implementation of the OpenG ii libglu1-mesa [libglu1 7.0.3-7The OpenGL utility library (GLU) ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpng12-01.2.27-2 PNG library - runtime ii libraptor11.4.18-1 Raptor RDF parser and serializer l ii libstdc++64.3.3-3The GNU Standard C++ Library v3 ii libwww-ssl0 5.4.0-11 The W3C-WWW library (SSL support) ii libwxbase2.8-02.8.7.1-1.1wxBase library (runtime) - non-GUI ii libwxgtk2.8-0 2.8.7.1-1.1wxWidgets Cross-platform C++ GUI t ii zlib1g1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages amaya recommends: ii amaya-doc 10.1~pre4+dfsg.0-2 Web Browser, HTML Editor and Testb ii ttf-freefont 20080323-3 Freefont Serif, Sans and Mono True amaya suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507587: CVE-2008-5282: multiple buffer overflows
Hi Nico, Many thanks for the additional digging into the code. I'm curently on holiday, but will try to find some time to work on bits. Will try to at least make an upload of 11.0.1 tomorrow. On Tue, 2008-12-23 at 16:29 +0100, Nico Golde wrote: Hi, CCed upstream. Similar things are done at other places. Looking on the overall code quality I suggest we remove amaya from lenny unless someone is willing to do a complete audit. Amaya isn't in Lenny, mainly because of a bug which was only fixed with the switch to wx2.8, but the release came in too late. Thanks again, Regis -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507587: CVE-2008-5282: multiple buffer overflows
Hi Steffen, Thanks for the report. I had a quick look at the advisory, apparently both attacks have the same origin, TtaWCToMBstring(). Will have a look at fixing it, CC'ing upstream, since I haven't seen anything about the advisory over there. Regis On Tue, December 2, 2008 19:20, Steffen Joeris wrote: Package: amaya Severity: grave Tags: security Justification: user security hole Hi, the following CVE (Common Vulnerabilities Exposures) id was published for amaya. CVE-2008-5282[0]: | Multiple stack-based buffer overflows in W3C Amaya Web Browser 10.0.1 | allow remote attackers to execute arbitrary code via (1) a link with a | long HREF attribute, and (2) a DIV tag with a long id attribute. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. Cheers Steffen For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5282 http://security-tracker.debian.net/tracker/CVE-2008-5282 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507080: amaya: should this package be removed?
Hi, On Thu, 2008-11-27 at 15:04 -0600, Raphael Geissert wrote: Source: amaya Version: 10.1~pre4+dfsg.0-2 Severity: serious User: [EMAIL PROTECTED] Usertags: proposed-removal Hi, While reviewing some packages, your package came up as a possible candidate for removal from Debian, because: * It has a long-standing RC bug The bug should have been fixed with the switch to wxwidgets2.8. Personnal lack of time means I haven't been able to confirm the problem is fully fixed. * Not in etch, and won't be in lenny Was not in Etch because of the same bug, won't be in Lenny because wx2.8 came late to unstable, and there has been no final release with it (due soon, was tagged in CVS last week). * Depends on libwww which is to be removed I already started work with upstream on porting Amaya to libcurl. But there again, not enough spare time to complete it. * It is almost unusable Can you please explain that ? Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507080: amaya: should this package be removed?
On Fri, November 28, 2008 09:48, Amaya wrote: Raphael Geissert wrote: Source: amaya Version: 10.1~pre4+dfsg.0-2 Severity: serious User: [EMAIL PROTECTED] Usertags: proposed-removal You are evil! Do not remove me from the archive! :) Somebody speak up! Well, as said in my other mail, we need a conversion to curl to keep Amaya in the archive... So be safe you will have to curl your hair. I see no other solution. Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489095: tellico: FTBFS: libtool: link: cannot find the library `/usr/lib/libkmime.la' or unhandled argument `/usr/lib/libkmime.la'
ressign 489095 libkcal2-dev thanks Hi, There must have been a change in the new kdepim source package. If the libkcal.la references libkmime.la, then libkcal2-dev package should have the right dependency. Thanks, Regis On Thu, 2008-07-03 at 10:15 +0200, Lucas Nussbaum wrote: Package: tellico Version: 1.3.2.1-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080702 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. Relevant part: make[4]: Entering directory `/build/user-tellico_1.3.2.1-1-amd64-Dlpixi/tellico-1.3.2.1-1/src' /usr/share/qt3/bin/moc ./entry.h -o entry.moc /usr/share/qt3/bin/moc ./configdialog.h -o configdialog.moc /usr/share/qt3/bin/moc ./entryiconview.h -o entryiconview.moc /usr/share/qt3/bin/moc ./document.h -o document.moc /usr/share/qt3/bin/moc ./exportdialog.h -o exportdialog.moc /usr/share/qt3/bin/moc ./collection.h -o collection.moc /usr/share/qt3/bin/moc ./filterview.h -o filterview.moc /usr/share/qt3/bin/moc ./fieldcompletion.h -o fieldcompletion.moc /usr/share/qt3/bin/moc ./entrymerger.h -o entrymerger.moc /usr/share/qt3/bin/moc ./controller.h -o controller.moc /usr/share/qt3/bin/moc ./groupview.h -o groupview.moc /usr/share/qt3/bin/moc ./loandialog.h -o loandialog.moc /usr/share/qt3/bin/moc ./borrowerdialog.h -o borrowerdialog.moc /usr/share/qt3/bin/moc ./detailedlistview.h -o detailedlistview.moc /usr/share/qt3/bin/moc ./upcvalidator.h -o upcvalidator.moc /usr/share/qt3/bin/moc ./progressmanager.h -o progressmanager.moc /usr/share/qt3/bin/moc ./reportdialog.h -o reportdialog.moc /usr/share/qt3/bin/moc ./importdialog.h -o importdialog.moc /usr/share/qt3/bin/moc ./fetchdialog.h -o fetchdialog.moc /usr/share/qt3/bin/moc ./collectionfieldsdialog.h -o collectionfieldsdialog.moc /usr/share/qt3/bin/moc ./loanview.h -o loanview.moc /usr/share/qt3/bin/moc ./entryeditdialog.h -o entryeditdialog.moc /usr/share/qt3/bin/moc ./mainwindow.h -o mainwindow.moc /usr/share/qt3/bin/moc ./entryview.h -o entryview.moc /usr/share/qt3/bin/moc ./viewstack.h -o viewstack.moc /usr/share/qt3/bin/moc ./statusbar.h -o statusbar.moc /usr/share/qt3/bin/moc ./filterdialog.h -o filterdialog.moc /usr/share/qt3/bin/moc ./fetcherconfigdialog.h -o fetcherconfigdialog.moc /usr/share/qt3/bin/moc ./entryupdater.h -o entryupdater.moc creating tellico.all_cpp.cpp ... i486-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/kde -I/usr/share/qt3/include -I. -I/usr/include/libxml2 -I/usr/include/libxml2 -I/usr/include/exempi-2.0 -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I../src/core -MT tellico.all_cpp.o -MD -MP -MF .deps/tellico.all_cpp.Tpo -c -o tellico.all_cpp.o tellico.all_cpp.cpp In file included from /usr/include/kde/kdebug.h:25, from ptrvector.h:17, from datavectors.h:17, from tellico_kernel.h:17, from tellico_utils.cpp:15, from tellico.all_cpp.cpp:2: /usr/share/qt3/include/qstring.h: In member function 'char QChar::latin1() const': /usr/share/qt3/include/qstring.h:197: warning: conversion to 'char' from 'int' may alter its value /usr/share/qt3/include/qstring.h: In member function 'void QChar::setCell(uchar)': /usr/share/qt3/include/qstring.h:222: warning: conversion to 'ushort' from 'int' may alter its value /usr/share/qt3/include/qstring.h: In member function 'void QChar::setRow(uchar)': /usr/share/qt3/include/qstring.h:223: warning: conversion to 'ushort' from 'int' may alter its value /usr/share/qt3/include/qstring.h: In constructor 'QChar::QChar(uchar, uchar)': /usr/share/qt3/include/qstring.h:267: warning: conversion to 'ushort' from 'int' may alter its value /usr/share/qt3/include/qstring.h: In constructor 'QStringData::QStringData(QChar*, uint, uint)': /usr/share/qt3/include/qstring.h:365: warning: conversion to 'unsigned int:30' from 'uint' may alter its value /usr/share/qt3/include/qstring.h:365: warning: conversion to 'unsigned int:30' from 'uint' may alter its value In file included from /usr/share/qt3/include/qobject.h:48, from /usr/include/kde/kcommand.h:26, from tellico_kernel.h:20, from tellico_utils.cpp:15, from tellico.all_cpp.cpp:2: /usr/share/qt3/include/qevent.h: In member function 'void QDropEvent::setAction(QDropEvent::Action)': /usr/share/qt3/include/qevent.h:523: warning: conversion to 'unsigned char' from 'uint' may alter its value In file included from
Bug#477962: tellico: FTBFS: Nonexistent build-dependency: libyaz2-dev
Hi, The bug is not actually about building with gcc 4.3 but because of the libyaz transition. A new package fixing the FTBS is already waiting in NEW. Thanks, Regis On Sat, 2008-04-26 at 02:46 +0200, Lucas Nussbaum wrote: Package: tellico Version: 1.3.1-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080425 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now the default on most architectures (even if it's not the case on i386 yet). Feel free to downgrade this bug to 'important' if your package is only built on i386, and this bug is specific to gcc 4.3 (i.e the package builds fine with gcc 4.2). Relevant part: ** Using build dependencies supplied by package: Build-Depends: debhelper (= 5.0.51~), kdelibs4-dev, kdemultimedia-dev, libexempi-dev, libkcal2-dev, libpoppler-qt-dev, libqt3-mt-dev, libtag1-dev, libxml2-dev, libxslt1-dev, libyaz2-dev Checking for already installed source dependencies... debhelper: missing Using default version 7.0.2 kdelibs4-dev: missing kdemultimedia-dev: missing libexempi-dev: missing libkcal2-dev: missing libpoppler-qt-dev: missing libqt3-mt-dev: missing libtag1-dev: missing libxml2-dev: missing libxslt1-dev: missing libyaz2-dev: missing Checking for source dependency conflicts... Reading package lists... Building dependency tree... Reading state information... Package libyaz2-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libyaz2-dev has no installation candidate The full build log is available from: http://people.debian.org/~lucas/logs/2008/04/25 A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing a sid i386 environment. Internet was not accessible from the build systems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414380: Still a problem in 9.55~dfsg.0-1
Yes, yes, yes, I know, no need to remind me. This seems to be fixed with Amaya 10, with which I still have some issues, and can only upload to experimental because of the wxWidgets 2.8 dependency anyway. Regis On Sun, 2008-04-06 at 18:35 +0100, Ralph Janke wrote: This crash still happens in 9.55~dfsg.0-1 just during startup. See also (https://bugs.launchpad.net/ubuntu/+source/amaya/+bug/86575) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440436: Amaya will be hurt
On Thu, 2008-01-03 at 21:49 +0100, Richard Atterer wrote: OK, the good news is, upstream reacted very positively to my suggestion to switch to libcurl. That's great! TBH, I'm not too surprised, libwww _is_ difficult to get to work at times. I was more referring to issues I have with amaya upstream to get some patches included. There a couple I've had for over a year. One thing I'm not sure about yet is how to handle WebDAV with it. Not much of a problem for me at the moment anyway, considering the feature is disabled in both libwww and Amaya... WebDAV support is raised on the libcurl mailing list from time to time. Curl doesn't directly support WebDAV, but you can generate quite arbitrary HTTP-like requests with it, including overwriting the request method with e.g. MKCOL rather than GET/POST. So it should be possible to get it to work. Alternatively, WebDAV support could be added to curl. Having hacked libcurl on several occasions, I can say that its code is quite beautiful and fun to work with, in contrast to libwww... Well, or look at libneon. Sounds good to me :) mapserver is actually a false positive, they switched to libcurl ages ago, bug filed. Seems to be the case with xdvik-ja too. Which only leaves : amaya liboop (reverse b-dep are lsh-utils, and ruli) wmweather+ xmlrpc-c (reverse b-dep are libapache2-mod-xmlrpc2, openser, and rtorrent) As I wrote previously, I will be happy to take over maintainership until it can be actually removed. How do you want me to handle this ? Simply make an upload setting myself as new maintainer ? Yes, feel free to take over maintainership this way! (Close this bug with the upload if you do plan to take it over permanently, and not only until Amaya has moved to libcurl.) Actually, liboop has had the libwww bit disabled for years, and xmlrpc-c already has a libcurl connector. I already filed bugs for the 4 easy ones, which only leaves amaya and wmweather+. I sincerely hope to get rid of libwww at some point. BTW, if you keep the package in the archive, consider getting rid of the non-SSL versions. I introduced them because of possible license incompatibilities between any GPL packages and OpenSSL, but last time I checked (=a long time ago!;-), there weren't actually any such problems with the current depends in the Debian archive. I'm not sure I want to do that much work on this package ;) Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440436: Amaya will be hurt
On Sat, December 15, 2007 11:42, Richard Atterer wrote: On Fri, Dec 14, 2007 at 05:38:12PM -, Regis Boudin wrote: Amaya build-depends on libwww and seriously relies on it. Removing it will put me in a quite uncomfortable situation. I would like to avoid following upstream who use a statically built and linked version of the library if I can. Hmm, OK. Using a statically linked version would have been my first suggestion. I could try to push them towards libcurl, though I'm afraid they won't react well... Having tried to create a program using both libwww and libcurl, I can say that libcurl is _much_ better in every aspect. These days, libcurl can even do HTTP pipelining, which was only supported by libwww for a long time. OK, the good news is, upstream reacted very positively to my suggestion to switch to libcurl. One thing I'm not sure about yet is how to handle WebDAV with it. Not much of a problem for me at the moment anyway, considering the feature is disabled in both libwww and Amaya... Would you maybe be interested in taking over maintainership of libwww? BTW, currently the following unstable packages build-dep on libwww: amaya liboop mapserver wmweather+ xdvik-ja xmlrpc-c mapserver is actually a false positive, they switched to libcurl ages ago, bug filed. Seems to be the case with xdvik-ja too. Which only leaves : amaya liboop (reverse b-dep are lsh-utils, and ruli) wmweather+ xmlrpc-c (reverse b-dep are libapache2-mod-xmlrpc2, openser, and rtorrent) As I wrote previously, I will be happy to take over maintainership until it can be actually removed. How do you want me to handle this ? Simply make an upload setting myself as new maintainer ? Regis
Bug#440436: Amaya will be hurt
On Sat, December 15, 2007 11:42, Richard Atterer wrote: On Fri, Dec 14, 2007 at 05:38:12PM -, Regis Boudin wrote: Amaya build-depends on libwww and seriously relies on it. Removing it will put me in a quite uncomfortable situation. I would like to avoid following upstream who use a statically built and linked version of the library if I can. Hmm, OK. Using a statically linked version would have been my first suggestion. Well, even if I were to adopt the libwww package and Amaya was the last software using it, I would rather keep them separated to make the whole thing less of a pain to maintain, and not have to rebuild Amaya just to fix a bug in the library. Remember the old days when XFree86 was a single gigantic source package... I could try to push them towards libcurl, though I'm afraid they won't react well... Having tried to create a program using both libwww and libcurl, I can say that libcurl is _much_ better in every aspect. These days, libcurl can even do HTTP pipelining, which was only supported by libwww for a long time. I surely will work towards this solution, though my experience with upstream makes me believe it's going to be a veery long process to get it accepted... Would you maybe be interested in taking over maintainership of libwww? That's something I could consider. However, more in a maintained end-of-life cycle way than properly active maintainership. Will probably wait for new year to do that anyway, as I will be on holiday from this evening until the 1st. BTW, currently the following unstable packages build-dep on libwww: amaya liboop mapserver wmweather+ xdvik-ja xmlrpc-c I guess I will check with them to see if they have plans to move away from libwww. Thanks, Regis
Bug#456373: Bugs tagging
tags 456373 moreinfo unreproducible severity 456373 important thanks This this bug was only visible in one case, right after an upgrade of KDE from 3.5.5 to 3.5.8 which is known to cause trouble and crashes for all KDE apps, and I can't reproduce it, and tagging accordingly. Considering the strongest candidate for the cause of the problem is actually a KDE-upgrade related issue, downgrade severity to important untill I get confirmation that the problem is actually in tellico. Mark, can you please confirm whether tellico works fine with a complete logout and log back in ? Regis
Bug#456373: tellico: crashes when starting, SIGSEGV, kio, application/octet-stream
Hi Mark, Thanks for the report. However, I can't reproduce it on my machine. Did you try to log out and back in ? It seems the error messages you got happen when people don't do it after a KDE upgarde. Considering you went from 3.5.5 to 3.5.8, I guess it could be related. If you could test this (or start with a different account), it would be very helpful. Regis On Fri, 2007-12-14 at 19:42 -0500, Mark Whitis wrote: Package: tellico Version: 1.2.14-1 Severity: grave Justification: renders package unusable Just installed tellico, which also updated a bunch of KDE stuff. When starting tellico pops up a window Could not find mime type application/octet-stream, the following error messages appear on stderr/stdout and Kcrash starts. Kcrash itself will also display the application/octet-stream message when saving the backtrace. kio (KSycoca): WARNING: Found version 93, expecting version 94 or higher. kio (KSycoca): WARNING: Outdated database found kio (KSycoca): WARNING: Found version 93, expecting version 94 or higher. kio (KSycoca): WARNING: Outdated database found [here is where Could not find mime type application/octet-stream appears] KCrash: Application 'tellico' crashing... (no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0xb5ae86c0 (LWP 27232)] [KCrash handler] #5 0x081131f6 in ?? () #6 0x083b9680 in ?? () #7 0xbfffccec in ?? () #8 0x in ?? () #9 0xb6b136e9 in QGDict::clear (this=0x82c5758) at tools/qgdict.cpp:770 #10 0x08113832 in ?? () #11 0x082c5758 in ?? () #12 0xb7fa6780 in ?? () from /lib/ld-linux.so.2 #13 0xb721be35 in KMainWindow::qt_invoke () from /usr/lib/libkdeui.so.4 Backtrace stopped: previous frame inner to this frame (corrupt stack?) rm -R /tmp/ksocket-whitis/ /tmp/kde-whitis/ does not help. http://lists.kde.org/?l=kde-bugs-distm=99057005025871w=2 kdeinit doesn't help killall kdeinit kio_uiserver knotify dcopserver kded also doesn't help. but finally running kdeinit again allows the program to start, though kdeinit still displays a lot of kbuildsycoca errors. apt-get install tellico Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: blender fyre kcontrol kdebase-bin kdebase-bin-kde3 kdebase-data kdebase-kio-plugins kdegraphics-kfile-plugins kdelibs-data kdelibs4c2a kdesktop kdm kfind kicker konqueror kpersonalizer ksplash libhal-storage1 libhal1 libkcal2b libkcddb1 libkdepim1a libkonq4 libktnef1 libopenexr2ldbl libpoppler-qt2 libpoppler2 libssl-dev libssl0.9.8 libyaz2 tellico-data Suggested packages: yafray ntpdate ntp-simple The following packages will be REMOVED libopenexr2c2a The following NEW packages will be installed kdebase-bin-kde3 libopenexr2ldbl libpoppler-qt2 libpoppler2 libyaz2 tellico tellico-data The following packages will be upgraded: blender fyre kcontrol kdebase-bin kdebase-data kdebase-kio-plugins kdegraphics-kfile-plugins kdelibs-data kdelibs4c2a kdesktop kdm kfind kicker konqueror kpersonalizer ksplash libhal-storage1 libhal1 libkcal2b libkcddb1 libkdepim1a libkonq4 libktnef1 libssl-dev libssl0.9.8 25 upgraded, 7 newly installed, 1 to remove and 1526 not upgraded. Need to get 61.1MB of archives. After unpacking 20.5MB of additional disk space will be used. Do you want to continue [Y/n]? y Get: 1 http://http.us.debian.org unstable/main konqueror 4:3.5.8.dfsg.1-2 [2033kB] Get: 2 http://http.us.debian.org unstable/main kdebase-kio-plugins 4:3.5.8.dfsg.1-2 [1132kB] Get: 3 http://http.us.debian.org unstable/main blender 2.45-1 [7205kB] Get: 4 http://http.us.debian.org unstable/main kdegraphics-kfile-plugins 4:3.5.8-2+b1 [255kB] Get: 5 http://http.us.debian.org unstable/main kdelibs4c2a 4:3.5.8.dfsg.1-4 [9828kB] 18% [5 kdelibs4c2a 548466/9828kB 5%] 179kB/s 4m38s^18% [5 kdelibs4c2a 822138/9828kB 8%] 179kB/s 4m37s^18% [5 kdelibs4c2a 913362/9828kB 9%] 179kB/s 4m36s^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[BGet: 6 http://http.us.debian.org unstable/main fyre 1.0.1-1+b1 [78.1kB] Get: 7 http://http.us.debian.org unstable/main libopenexr2ldbl 1.2.2-4.4 [305kB] Get: 8 http://http.us.debian.org unstable/main kdelibs-data 4:3.5.8.dfsg.1-4 [8693kB] Get: 9 http://http.us.debian.org unstable/main libkonq4 4:3.5.8.dfsg.1-2 [275kB] Get: 10 http://http.us.debian.org unstable/main kdesktop 4:3.5.8.dfsg.1-2 [787kB]
Bug#440436: Amaya will be hurt
Hi Richard, Amaya build-depends on libwww and seriously relies on it. Removing it will put me in a quite uncomfortable situation. I would like to avoid following upstream who use a statically built and linked version of the library if I can. I could try to push them towards libcurl, though I'm afraid they won't react well... Regis
Bug#449527: Crash by using internet search
Hi again, With my account finally created, I uploaded a new release of Tellico to the archive. According to Robby, there should be a fix for this crash in it. Could you please test if it is the case, so I can close this bug ? Thanks for your help, Regis On Tue, November 6, 2007 10:23, Victor-Philipp Busch wrote: Package: tellico Version: 1.2.11-1 Severity: critical --- Please enter the report below this line. --- Hello, tellico crashs if I'm using the internet search with my movie database (300 entrys). I can search and I see the result, but if I add the movie, tellico crashs. If I open a new database and use the internet search it works all fine. Here is the debug ouput: (no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0xb60de8d0 (LWP 14963)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [KCrash handler] #5 0x080ea6ef in ?? () #6 0x089e7078 in ?? () #7 0xbfb3cf10 in ?? () #8 0xbfb3cee8 in ?? () #9 0x080ebb26 in ?? () #10 0x08482df0 in ?? () #11 0x0001 in ?? () #12 0x0891d7c0 in ?? () #13 0x080eaf6a in ?? () #14 0x086a6f40 in ?? () #15 0x0001 in ?? () #16 0xbfb3cf90 in ?? () #17 0x08953cc8 in ?? () #18 0x085fa148 in ?? () #19 0x08a27f38 in ?? () #20 0x085fa148 in ?? () #21 0x0004 in ?? () #22 0xbfb3cf68 in ?? () #23 0xbfb3cf6c in ?? () #24 0xbfb3cf28 in ?? () #25 0x080f75ea in ?? () #26 0x089e7078 in ?? () #27 0xbfb3cf14 in ?? () #28 0xbfb3cf10 in ?? () #29 0xbfb3cf0c in ?? () #30 0x in ?? () #31 0xbfb3cf24 in ?? () #32 0x08413cf0 in ?? () #33 0x085fa148 in ?? () #34 0x08a27f38 in ?? () #35 0x08a26ce8 in ?? () #36 0xb6707140 in ?? () from /lib/libc.so.6 #37 0x0861e598 in ?? () #38 0x0861e5a4 in ?? () #39 0x0861e5a0 in ?? () #40 0xbfb3cf88 in ?? () #41 0x08238dcc in ?? () #42 0x08413cc0 in ?? () #43 0xbfb3cf6c in ?? () #44 0xbfb3cf68 in ?? () #45 0xbfb3cf64 in ?? () #46 0x0008 in ?? () #47 0x084777e8 in ?? () #48 0xb7309470 in ?? () from /usr/lib/libkdeui.so.4 #49 0xb6e42fd1 in QGListIteratorList::add () from /usr/lib/libqt-mt.so.3 Backtrace stopped: previous frame inner to this frame (corrupt stack?) --- System information. --- Architecture: i386 Kernel: Linux 2.6.21.3 Debian Release: lenny/sid 500 unstableftp.de.debian.org 500 testing security.debian.org 500 debian-unstable download.tuxfamily.org --- Package information. --- Depends (Version) | Installed ===-+-=== tellico-data (= 1.2.11-1) | 1.2.11-1 kdelibs4c2a (= 4:3.5.6-1)
Bug#449527: Crash by using internet search
Hi, On Tue, November 6, 2007 10:23, Victor-Philipp Busch wrote: Package: tellico Version: 1.2.11-1 Severity: critical --- Please enter the report below this line. --- Hello, tellico crashs if I'm using the internet search with my movie database (300 entrys). I can search and I see the result, but if I add the movie, tellico crashs. If I open a new database and use the internet search it works all fine. Thanks for the report. I think I remember this issue coming up already at some point before. Will try to look further... Regis --- System information. --- Architecture: i386 Kernel: Linux 2.6.21.3 Debian Release: lenny/sid 500 unstableftp.de.debian.org 500 testing security.debian.org 500 debian-unstable download.tuxfamily.org --- Package information. --- Depends (Version) | Installed ===-+-=== tellico-data (= 1.2.11-1) | 1.2.11-1 kdelibs4c2a (= 4:3.5.6-1) | 4:3.5.8.dfsg.1-3 libc6(= 2.5-5) | 2.6.1-6 libkcal2b (= 4:3.5.6) | 4:3.5.8-1 libkcddb1(= 4:3.5.6-1) | 4:3.5.8-1 libqt3-mt (= 3:3.3.7) | 3:3.3.7-9 libstdc++6 (= 4.1.2) | 4.2.2-3 libtag1c2a (= 1.4) | 1.4-8+b1 libxml2 (= 2.6.28) | 2.6.30.dfsg-2 libxslt1.1 (= 1.1.18) | 1.1.22-1 libyaz2 (= 2.1.18) | 2.1.18-2
Bug#403058: xtla: FTBFS: b-dep on emacs-snapshot, which is not in testing
Hi, For the record, emacs-snapshot was removed from unstable as well, so xtla definitely needs to be updated and this build-dep to be removed. Regis
Bug#394239: Should we keep testresources in the archive ?
Hi, This package has been in an FTBS situation for almost one year now, without a fix or a reply to the bugs. Please tell us what your plans are regarding testresources, whether you plan to maintain it actively, orphan it, or if it should be removed from Debian. Thanks, Regis
Bug#422373: schooltool status ?
Hi, This FTBFS bug has been open for 4 months without a reply, and one of the b-deps was removed 3 months ago. What's your plan ? Is this package still actively maintained ? Regis
Bug#435442: Patch
tags 435442 patch
thanks
Hi,
The simplest solution to this is to conflicts against versions older than
the dummy package when it was introduced, that is 2.5-1, instead of trying
to do that against the current one.
The attached patch does that, as well as using ${binary:Version} instead
of ${Source-Version} and removing the undefined Bugs: field to remove a
couple of lintian messages.
Also, it seems to me that the build-dependency on libsndfile-dev is
unnecessary, as the code never uses its header or tries to link against
it.
RegisIndex: faad2-2.5/debian/control
===
--- faad2-2.5.orig/debian/control 2007-08-20 00:27:55.0 +0100
+++ faad2-2.5/debian/control 2007-08-20 00:36:51.0 +0100
@@ -2,14 +2,13 @@
Section: libs
Priority: optional
Maintainer: Matthew W. S. Bell [EMAIL PROTECTED]
-Bugs: mailto:[EMAIL PROTECTED]
Standards-Version: 3.7.2
Build-Depends: debhelper ( 4), libsndfile1-dev, xmms-dev, libid3-dev, dpatch, libtool, autotools-dev
Package: libfaad0
Architecture: any
Depends: ${shlibs:Depends}
-Conflicts: libfaad2-0 ( ${Source-Version})
+Conflicts: libfaad2-0 ( 2.5-1)
Replaces: libfaad2-0
Description: freeware Advanced Audio Decoder - runtime files
FAAD2 is the fastest ISO AAC audio decoder available. FAAD2 correctly
@@ -18,7 +17,7 @@
Package: libfaad2-0
Architecture: all
-Depends: libfaad0 (= ${Source-Version})
+Depends: libfaad0 (= ${binary:Version})
Description: freeware Advanced Audio Decoder - dummy package
FAAD2 is the fastest ISO AAC audio decoder available. FAAD2 correctly
decodes all MPEG-4 and MPEG-2 MAIN, LOW, LTP, LD and ER object type AAC
@@ -30,7 +29,7 @@
Package: libfaad-dev
Section: libdevel
Architecture: any
-Depends: libfaad0 (= ${Source-Version}), libc6-dev | libc-dev
+Depends: libfaad0 (= ${binary:Version}), libc6-dev | libc-dev
Conflicts: libfaad2-dev
Replaces: libfaad2-dev
Description: freeware Advanced Audio Decoder - development files
Bug#279655: Status of silgraphite1.0 ?
Hi, This package, silgraphite1.0, has had a single upload to experimental almost 3 years ago, and an FTBFS bug open against it since November 2004. Is it worth keeping it in the archive ? If it's not, please ask ftp-master to remove it. Thanks, Regis
Bug#425968: tellico: wrong translation to German
tags 425968 +upstream
found 425968 1.2.11-1
severity 425968 important
thanks
Hi,
This loss of data is not in the sense that it will actually make existing
data disappear and break your existing collection, rather it doesn't
export them in the expected format. So I'm lowering priority to non-RC.
This bug is present in Etch. I will try to get a fix included in a point
release, but I can't promise it will be accepted by the SRMs.
These translations are still in the upstream svn, CCing Jens who takes
care of the de translation so I can get his input and possibly a fix for
it.
Thanks for the report,
Regis
On Fri, May 25, 2007 10:36, Johannes Wiedersich wrote:
Package: tellico
Version: 1.2.5-1
Severity: grave
Justification: causes non-serious data loss
The German translation is errenous.
'Editor' is translated as 'Verfasser', but 'Verfasser' means author.
Correct translation would be 'Herausgeber'.
'Publisher' is translated as 'Herausgeber', but 'Herausgeber' means
editor. Correct translation would be 'Verlag'.
'Organization' is translated as 'Unternehmen', but might be better
translated simply as 'Organisation'.
The resulting data base is unusable by external tools like Latex, hence
'causes non-serious data loss'.
I include a bibtex export for a 'book', where I used Tellico's description
as content for the various fields.
@book{Bibtex-schluessel,
title = {Titel},
author = {Autor},
booktitle = {Buch-Titel},
editor = {Verfasser},
organization = {Unternehmen},
publisher = {Herausgeber},
address = {Adresse},
edition = {Auflage},
pages = {Seiten},
year = 1000,
journal = {Zeitung},
month = {12},
number = 1,
howpublished = {art d. V.},
chapter = 1,
series = {Serie},
volume = 1,
crossref = {Querverweis}
}
Johannes
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages tellico depends on:
ii kdelibs4c2a4:3.5.5a.dfsg.1-8 core libraries and binaries
for al
ii libc6 2.3.6.ds1-13 GNU C Library: Shared
libraries
ii libgcc11:4.1.1-21GCC support library
ii libkcal2b 4:3.5.5.dfsg.1-6 KDE calendaring library
ii libkcddb1 4:3.5.5-2 CDDB library for KDE
ii libqt3-mt 3:3.3.7-4 Qt GUI Library (Threaded
runtime v
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library
v3
ii libtag1c2a 1.4-4 TagLib Audio Meta-Data
Library
ii libxml22.6.27.dfsg-1 GNOME XML library
ii libxslt1.1 1.1.19-1 XSLT processing library -
runtime
ii libyaz22.1.18-2 The YAZ Z39.50 toolkit
(runtime fi
ii tellico-data 1.2.5-1 collection manager for books,
vide
tellico recommends no packages.
-- no debconf information
Bug#423585: amaya: Please remove or lower dependency on ttf-freefont
Hi, Thanks for the additional informations. The next upload will fix the dependency. I will check with upstream if they plan to make a new release soon before, though. Regis On Wed, May 16, 2007 02:49, Theppitak Karoonboonyanan wrote: severity 423585 serious thanks Up severity, as this violates Debian Policy (11.8.5: Packages must not Depend on font packages.) -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/
Bug#416610: Status of the orca and tinysnmp packages ?
Hi, The orca package was last uploaded in July 2004 (same age as the latest upstream release), has 5 RC bugs open against it, needs to be ported to the new rrd and tinysnmp APIs since 2 years ago. Is this package still active upstream and maintained ? Or should we request for its removal ? Same goes for tinysnmp, with the same maintainer (also upstream), last uploaded 2 years ago, 4 RC bugs, never in a stable release. CC'ing QA, the maintainer might actually be MIA... Regis signature.asc Description: This is a digitally signed message part
Bug#414380: amaya does not start. X Window System error serial 10426 error_code 8 request_code 144 minor_code 5
Yes, yes I know. This bug is actually a mixed thing somewhere between wxWidgets, Mesa and Xorg. And you're running GLX without DRI, which is (almost) the only situation triggering the bug I have seen. For more informations, see bug #357439 : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357439 Regis On Sun, 2007-03-11 at 11:43 +0100, Adrien Grellier wrote: Package: amaya Version: 9.53~dfsg.0-1 Severity: grave Justification: renders package unusable I can't start amaya, and I have this message : (amaya:2766): Gtk-CRITICAL **: gtk_widget_set_colormap: assertion `!GTK_WIDGET_REALIZED (widget)' failed The program 'amaya' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 10426 error_code 8 request_code 144 minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) I use the unstable package. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages amaya depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii libfreetype6 2.2.1-5FreeType 2 font engine, shared lib ii libgcc1 1:4.1.1-21 GCC support library ii libgl1-mesa-glx [libgl1] 6.5.1-0.6 A free implementation of the OpenG ii libglu1-mesa [libglu1]6.5.1-0.6 The OpenGL utility library (GLU) ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libraptor11.4.13-1 Raptor RDF parser and serializer l ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii libwww-ssl0 5.4.0-11 The W3C-WWW library (SSL support) ii libwxbase2.6-02.6.3.2.1.5wxBase library (runtime) - non-GUI ii libwxgtk2.6-0 2.6.3.2.1.5wxWidgets Cross-platform C++ GUI t ii ttf-freefont 20060501cvs-10 Freefont Serif, Sans and Mono True ii zlib1g1:1.2.3-13 compression library - runtime amaya recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414380: amaya does not start. X Window System error serial 10426 error_code 8 request_code 144 minor_code 5
On Sun, 2007-03-11 at 20:50 +0100, Amaya wrote: Regis Boudin wrote: For more informations, see bug #357439 : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357439 Regis, do you think we can merge these? I'm not sure the BTS would be very happy about merging bugs assigned to different packages... Considering this bug only affects the package in some specific situations, I will probably downgrade it to important. And I will leave it assigned to this package, because if I reassign it to wxWidgets and merge, it will only be a couple of weeks before someone else opens the same bug again... If you have another idea on how to handle the situation, suggestions are welcome :) Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411744: Tellico has various RC bugs
Hi, On Wed, February 21, 2007 09:00, Steve Langasek wrote: On Tue, Feb 20, 2007 at 06:28:59PM +, Regis Boudin wrote: The tellico packag currently in etch and unstable has a couple of nasty bugs reported and fixed upstream, causing crashes and loss of data. Where are these nasty bugs described? This information is going to be relevant when reviewing the update for inclusion in etch. The full changelog of what I prepared reads : * New upstream release, aimed at Etch. Differences with 1.2.4-1 are : + Build fix for OOo plugin (disabled in the package anyway), r1206 + Check if pointer is NULL *before* using it, r1212. + Some minor build issues + Use log messages instead of debug * Also backport a bunch of bugfixes : + r1216 : fix crashing bug in progressitem. + r1224 : clear release list when removing an image. + r1228 : prevent an infinite loop. + r1245 r1248 : fix a race condition leading to loss of images. + r1265 : sometimes images wouldn't show up if the cover column was visible in the list view. + r1340 : sometimes z39.50 results would not show up. * Many thanks to Robby Stephenson, the uptream author, for his help picking the patches for inclusion. * Only call dh_compress once so help files are not compressed and can be read (Closes: #401247). So overall, there is a build fix, use of a NULL pointer, crash, memory leak, infinite loop, loss of data, non-showing of data and inaccessible documentation. The source package is in http://www.imalip.info/tellico/etch/ . Technically, it is a new upstream release. However, the previous package was more of a snapshot, the new release was done the next day or so, and the diff before the additional patches is really short ( that's the debdiff file in http://www.imalip.info/tellico/etch/ , it shouldn't take more than 20s to look at it completely). Considering the source code would be virtually the same with 2 bugfixes, I went for the almost new upstream option rather than the stack up patches on top of patches one. On top of it come the other .diff files, numbered after the svn referenced in the changelog. If anything is wrong with that, please tell me. Also I'm still not a DD and will need a sponsor anyway. CC'ing Amaya, She's been working with me on preparing this yesterday. Regis
Bug#411744: Tellico has various RC bugs
Package: tellico Version: 1.2.4-1 Severity: grave Tags: pending The tellico packag currently in etch and unstable has a couple of nasty bugs reported and fixed upstream, causing crashes and loss of data. A new package is ready to fix them, and will hopefully be uploaded very soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390270: amaya: Amaya corrupts files when saving
Ok pulling my head out of the car stuffs... First, thanks to Amaya for tagging the bug. Second, I now have an package based on upstream 9.53. The source package is available at http://www.imalip.info/amaya/ , for those who want to test/check it and possibly upload it, which would be nice (closing an RC bug stop me from expending the changelog entry). I finally rerolled the upstream tarball to remove non-free bits. Now I will have to push upstream to apply more of my patches... As usual, the applied patches are in debian/patches, and any comment or suggestion is welcome. CC'ing Joerg as my AM. I still don't know what I'm supposed to do, so let's show him what I'm working on... Thanks, and happy new year, Regis On Sat, January 6, 2007 01:33, Benjamin Woodacre wrote: This issue does not seem to appear in the latest upstream version, 9.53, released on 12 December. signature.asc Description: This is a digitally signed message part
Bug#390270: amaya: Amaya corrupts files when saving
Hi,
Thanks for the details. I tried it and didn't get the same problem as
you, , but still got some strange things. Attached is the result file
after simply adding a carriage return and a space, which contains some
funny characters, and is definitely a bug.
I also checked with a more recent version and will try with the CVS one,
before forwarding it upstream. (I need to rebuild it all first, however,
so it might take a bit).
Regis
On Sun, 2006-12-03 at 08:12 +0100, Georg Colle wrote:
Ok,
{1} Create a html file beginning with an xml statement, such as
?xml version=1.0 encoding=utf-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
title/title
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
/head
body/body
/html
{2}
Open it with Amaya and change it, e. g. by inserting a blank character.
Save it.
{3}
Open the saved file with a text editor and you will see what I mean.
Greetings,
Georg
Am Samstag, den 02.12.2006, 18:53 + schrieb Regis Boudin:
Hi,
Sorry for the delay in replying. The bug arrived at the wrong time and
found itself sort of lost...
Anyway, I don't really understand what the problem is, or how to trigger
it. Do you have a way to reproduce the problem, so that I can either try
to fix the problem or check with upstream ?
Regards,
Regis
On Sat, 2006-09-30 at 08:40 +0200, Georg Colle wrote:
Package: amaya
Version: 9.51-2.1
Severity: grave
Justification: renders package unusable
In the doctype tag 'PUBLIC xyz \n ' is inserted (xyz means arbitrary
charcters and \n
stands for the line feed charcter). At the end of the document, after a
line containing
'', the html-tag and the whole part of the document included within it
is repeated.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-amd64
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages amaya depends on:
ii libc6 2.3.6.ds1-4 GNU C Library: Shared
libraries
ii libexpat1 1.95.8-3.3XML parsing C library -
runtime li
ii libfreetype6 2.2.1-5 FreeType 2 font engine,
shared lib
ii libgcc11:4.1.1-14GCC support library
ii libgl1-mesa-glx [libgl1] 6.5.1-0.1 A free implementation of the
OpenG
ii libglu1-mesa [libglu1] 6.5.1-0.1 The OpenGL utility library
(GLU)
ii libjpeg62 6b-13 The Independent JPEG Group's
JPEG
ii libpng12-0 1.2.8rel-5.2 PNG library - runtime
ii libraptor1 1.4.12-1 Raptor RDF parser and
serializer l
ii librdf01.0.4-1 Redland Resource Description
Frame
ii libstdc++6 4.1.1-14 The GNU Standard C++ Library
v3
ii libwww-ssl05.4.0-11 The W3C-WWW library (SSL
support)
ii libwxbase2.6-0 2.6.3.2.1.5 wxBase library (runtime) -
non-GUI
ii libwxgtk2.6-0 2.6.3.2.1.5 wxWidgets Cross-platform C++
GUI t
ii ttf-freefont 20060501cvs-9 Freefont Serif, Sans and
Mono True
ii zlib1g 1:1.2.3-13compression library - runtime
amaya recommends no packages.
-- no debconf information
test.html
Description: application/xml
Bug#390270: amaya: Amaya corrupts files when saving
Ok,
After a bit of time to build the CVS version, I tried the same thing,
and the problem didn't appear.
Since I don't know which patch could have fixed the problem, I can't
backport it and I don't have time to search for it at the moment.
I will instead finnish my work on patches which I am completely redoing,
and make a new upstream version available.
Thanks again for the report and the help.
Regis
On Sun, 2006-12-03 at 08:12 +0100, Georg Colle wrote:
Ok,
{1} Create a html file beginning with an xml statement, such as
?xml version=1.0 encoding=utf-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
title/title
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
/head
body/body
/html
{2}
Open it with Amaya and change it, e. g. by inserting a blank character.
Save it.
{3}
Open the saved file with a text editor and you will see what I mean.
Greetings,
Georg
Am Samstag, den 02.12.2006, 18:53 + schrieb Regis Boudin:
Hi,
Sorry for the delay in replying. The bug arrived at the wrong time and
found itself sort of lost...
Anyway, I don't really understand what the problem is, or how to trigger
it. Do you have a way to reproduce the problem, so that I can either try
to fix the problem or check with upstream ?
Regards,
Regis
On Sat, 2006-09-30 at 08:40 +0200, Georg Colle wrote:
Package: amaya
Version: 9.51-2.1
Severity: grave
Justification: renders package unusable
In the doctype tag 'PUBLIC xyz \n ' is inserted (xyz means arbitrary
charcters and \n
stands for the line feed charcter). At the end of the document, after a
line containing
'', the html-tag and the whole part of the document included within it
is repeated.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-amd64
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages amaya depends on:
ii libc6 2.3.6.ds1-4 GNU C Library: Shared
libraries
ii libexpat1 1.95.8-3.3XML parsing C library -
runtime li
ii libfreetype6 2.2.1-5 FreeType 2 font engine,
shared lib
ii libgcc11:4.1.1-14GCC support library
ii libgl1-mesa-glx [libgl1] 6.5.1-0.1 A free implementation of the
OpenG
ii libglu1-mesa [libglu1] 6.5.1-0.1 The OpenGL utility library
(GLU)
ii libjpeg62 6b-13 The Independent JPEG Group's
JPEG
ii libpng12-0 1.2.8rel-5.2 PNG library - runtime
ii libraptor1 1.4.12-1 Raptor RDF parser and
serializer l
ii librdf01.0.4-1 Redland Resource Description
Frame
ii libstdc++6 4.1.1-14 The GNU Standard C++ Library
v3
ii libwww-ssl05.4.0-11 The W3C-WWW library (SSL
support)
ii libwxbase2.6-0 2.6.3.2.1.5 wxBase library (runtime) -
non-GUI
ii libwxgtk2.6-0 2.6.3.2.1.5 wxWidgets Cross-platform C++
GUI t
ii ttf-freefont 20060501cvs-9 Freefont Serif, Sans and
Mono True
ii zlib1g 1:1.2.3-13compression library - runtime
amaya recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390270: amaya: Amaya corrupts files when saving
Hi, Sorry for the delay in replying. The bug arrived at the wrong time and found itself sort of lost... Anyway, I don't really understand what the problem is, or how to trigger it. Do you have a way to reproduce the problem, so that I can either try to fix the problem or check with upstream ? Regards, Regis On Sat, 2006-09-30 at 08:40 +0200, Georg Colle wrote: Package: amaya Version: 9.51-2.1 Severity: grave Justification: renders package unusable In the doctype tag 'PUBLIC xyz \n ' is inserted (xyz means arbitrary charcters and \n stands for the line feed charcter). At the end of the document, after a line containing '', the html-tag and the whole part of the document included within it is repeated. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-amd64 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages amaya depends on: ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libexpat1 1.95.8-3.3XML parsing C library - runtime li ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-14GCC support library ii libgl1-mesa-glx [libgl1] 6.5.1-0.1 A free implementation of the OpenG ii libglu1-mesa [libglu1] 6.5.1-0.1 The OpenGL utility library (GLU) ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libraptor1 1.4.12-1 Raptor RDF parser and serializer l ii librdf01.0.4-1 Redland Resource Description Frame ii libstdc++6 4.1.1-14 The GNU Standard C++ Library v3 ii libwww-ssl05.4.0-11 The W3C-WWW library (SSL support) ii libwxbase2.6-0 2.6.3.2.1.5 wxBase library (runtime) - non-GUI ii libwxgtk2.6-0 2.6.3.2.1.5 wxWidgets Cross-platform C++ GUI t ii ttf-freefont 20060501cvs-9 Freefont Serif, Sans and Mono True ii zlib1g 1:1.2.3-13compression library - runtime amaya recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357439: Trying another compile option ?
Hi, On Tue, November 14, 2006 12:28, LENHOF Jean-Yves said: I saw on this page that there are about three ways to compile amaya http://www.w3.org/Amaya/User/Autoconf.html Compiling with GTK+ seems not so interesting because of the SVG support... AFAIK, SVG support is independant from the toolkit used. But for now as I've seen on the debian rules file, amaya is compiled with this option : --with-wx --with-gl Perhaps compiling with this option : --with-wx and choosing to link against mesa instead of opengl will make the problem vanish... What this option (or the lack of using it) actually does, is build the whole Mesa in full software rendering mode and statically link against it. It means the package would have to include the Mesa source code, which would have to be rebuilt on every single arch. I really don't plan to track bug and security fixes in a software as tricky as Mesa, especially when it would be duplicated work, when the source is a 2 year old snapshot, and I don't actually have time to do it. Doing this would also mean that nobody would benefit from OpenGL hardware acceleration at all. So I'm not very inclined to go for this solution. I would rather link statically against libgl1-mesa-swx11, which would give the same result, with less code to maintain and build, but would only be slightly less bad, as I would still have to track every important bug or security fix in Mesa to trigger a rebuild of the package. Regis
Bug#357439: Amaya crash : some more DRI/GLX information
OK, After some more tests, I noticed that if I disable acceleration with DRIConf, Amaya still work but is very slow, while it crashes when I disable DRI from the xorg.conf. CC'ing Michel, as this information gives him a more precise idea about where the problem can be tracked down. Also, Michel, in a previous mail on this issue, you mentioned that it worked for you with the experimental versions of Mesa and X Server. I tried running the X server 1.1.99.901, and it still crashed. Any help is welcome, otherwise I will start to try sacrificing chickens. Regis
Bug#380014: Uninstallable due to unmet dep on libyaz
Hi, Considering that : -I'm not a DD -My usual sponsor is on holidays -I checked the package builds and runs without a problem by only changing 'libyaz-dev' by 'libyaz2-dev' in the Build-Depends I will be more than happy to see someone do a NMU with this trivial fix. (Modulo the fact the kdelibs4-dev is not installable at the moment...) Thanks, Regis On Wed, 2006-07-26 at 23:00 +0200, Luk Claes wrote: Package: tellico Severity: serious Version: 1.1.6-1 Hi Your package is not installable as it depends on libyaz which is not available in unstable anymore. You might want to update that dependency to libyaz2 (by changing the build-dep to libyaz2-dev for a start). Cheers Luk -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal signature.asc Description: This is a digitally signed message part
Bug#357439: amaya_wx-9.51-1_i386.deb from Amaya website works on Debian
Yes, no need for more reports, please. I know it works with the W3C-provided package and not with the Debian-provided one. The problem is : The amaya package provided by the W3C uses a statically (built and) linked libGL, unsing the full software rendering, equivalent to the libgl1-mesa-swx11 package in Debian. The package in Debian uses shared libraries for wxWidgets and libGL. In most cases, the installed packages for libGL are libgl1-mesa-dri and libgl1-mesa-glx by default. The DRI version is buggy and gives rendering bugs on ATI radeon cards. When people disable DRI (or don't have it available), it reverts to GLX rendering, where this bug appears. If you install libgl1-mesa-swx11, miracle, no more crash, rendering is fine, only painfully slow. Use another OpenGL library (say, the Nvidia proprietary one), everything is fine. All this would point to a bug in libgl1-mesa-glx, hence CC'ing debian-x and Michel more specifically in case he has some more ideas since a couple of month ago. Also, for the record, having read about some rendering bugs fixed with DRI on radeon when using the mesa packages from experimental, I tried them. The crash is still present with GLX, using DRI gives yet another creative way to not work : The screen freezes except the mouse cursor can move, keys don't seem to work at all, and the only way to get to a usable state was to ssh to the machine and kill amaya. The problem seems to be definitely with OpenGL. I thought about reassigning this bug the libgl1-mesa-glx, but I have so many different ways to see the thing crash or do strange things, I suspect there might actually be a problem in Amaya (or wxWidgets) doing nasty things with OpenGL. Michel, it would be nice to have your opinion about it. Any help/input/idea/miracle to fix this bug is welcome, before I try to sacrifice chickens. Regis Egor Kobylkin said: Hi, I have radeon M6-L and no DRI and I had the same problem with the amaya I have installed with apt-get install with deiban testing/unstable. After I have installed amaya_wx-9.51-1_i386.deb from Amaya web site it started to work. [EMAIL PROTECTED]:~$ amaya --sync 03:30:37 PM: Deleted stale lock file '/home/egork/.amaya-egork'. (amaya:5498): Gtk-CRITICAL **: gtk_widget_set_colormap: assertion `!GTK_WIDGET_REALIZED (widget)' failed The program 'amaya' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 12411 error_code 8 request_code 144 minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [EMAIL PROTECTED]:~$ su Password: barmaglot:/home/egork# dpkg -i amaya_wx-9.51-1_i386.deb (Reading database ... 118461 files and directories currently installed.) Preparing to replace amaya 9.51-2 (using amaya_wx-9.51-1_i386.deb) ... Unpacking replacement amaya ... Setting up amaya (wx-9.51-1) ... exit [EMAIL PROTECTED]:~$ amaya OpenGL Status: Software Mode = Soft VENDOR : Brian Paul VERSION : 1.5 Mesa 6.2.1 RENDERER : Mesa X11 GLU Version : 1.3 Aux buffers count 0 Acumm rgba : 0 0 0 0 -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#357439: amaya does not start
Hi, CCing debian-x again, Michel Dänzer might be interested and have some advice on what to try next. Ian Zimmerman said: The ovbious next data point would be - do the upstream packages work with Composite enabled? Or have you already done that? Yes, I have, and it doesn't work. Actually, I now have what seems to be a consistent result, assuming the upstream package uses the pure software rasteriser, which seems to be the case (Mesa built with the linux-static target) : - With libgl1-mesa-dri (DRI enabled) on a Radeon card : display bug(s). I get the same problem with other OpenGL apps (glxgears and googleearth). - With libgl1-mesa-glx (DRI disabled) : crash with the gdk error which has been reported several times and the backtrace I sent previously. Tested with ati and vesa drivers. - With libgl1-mesa-swx11 and no Composite : works fine, but slow. - With libgl1-mesa-swx11 and Composite : crash, with a different gdk error. I'm not sure about the Composite thing, but it looks like the crashing bug everybody complains about is closely related to GLX. Any help/advice is still welcome, though I'm not sure Amaya is actually the problem. Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#357439: amaya does not start--The program 'amaya' received an X Window System error.
Michel Dänzer said: I know. The previously attached backtrace was obtained with libgl1-mesa-swx11, running amaya with the --sync parameter, so there might be a problem there too. Doing the same with libgl1-mesa-glx and DRI disabled, I get the attached one. Could wxWidgets be doing something bad ? Possibly; in particular in the previous backtrace, it does look like either wx or GTK is the culprit. In this case, it looks like it could be wx and/or libGL and/or the X server. Follow-up on this bug. Upstream proposes packages on its website, built on Sarge. It is linked statically against local versions of Mesa and wxWidgets, which are included in the tarball and built before actually compiling the Amaya binary itself. The important detail, I guess, is that the provided Mesa is branded as being 6.2.1. My various tests have been done on an up-to-date unstable. Using the static wxWidgets and shared Mesa leads to the gdk error. Using the static wxWidgets and static Mesa works. However, it crashes with the same gdk error if the Composite extension is enabled. I'm not sure if this points more towards a problem with Mesa or X, but I feel all this is becoming quite complicated. Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#367642: amaya_9.51-1(amd64/unstable): FTBFS on 64bit architectures: error: cast from 'void*' to 'int' loses precision
tags 367642 +pending thanks Frederik Schüler said: Package: amaya Version: 9.51-1 Severity: serious Hello, There was an error while trying to autobuild your package: Yeah, I know, already noticed it. I guess I shouldn't trust upstream when they say they applied my patches... Well, actually, they did. Partially. Thanks for the report anyway. Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#357439: amaya does not start--The program 'amaya' received an X Window System error.
On Thu, 2006-04-27 at 18:28 +0200, Michel Dänzer wrote: All running tests point to a problem with Mesa : -crash with Mesa in software mode You mean the X error from the original report? Yes, I meant this one. Did you find out which extension generates it using xdpyinfo -queryExt|grep 144 ? I didn't know about xdpyinfo. If I start Amaya without DRI, I get an error with request_code 143, and : $ xdpyinfo -queryExt|grep 143 GLX (opcode: 143, base event: 77, base error: 154) SGI-GLX (opcode: 143, base event: 77, base error: 154) Is says GLX, which is consistent with what I supposed at least. -no crash with the nvidia proprietary driver, display is happy. When I tried using gdb to get a backtrace(attached), all I got was a long list of calls involving wxWidgets, GTK, but not Mesa. X is asynchronous, so the client receives the error long after it sent out the request causing it. When this happens, GTK should tell you how to make it use a synchronous X connection. I know. The previously attached backtrace was obtained with libgl1-mesa-swx11, running amaya with the --sync parameter, so there might be a problem there too. Doing the same with libgl1-mesa-glx and DRI disabled, I get the attached one. Could wxWidgets be doing something bad ? CCing the XSF in case someone has an idea, A Mesa list might have been even better? :) Sorry, I didn't find the debian-mesa list :) OpenGL Status: Software Mode = Hard VENDOR : Tungsten Graphics, Inc. VERSION : 1.2 Mesa 6.4.1 RENDERER : Mesa DRI Radeon 20050528 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL GLU Version : 1.3 Aux buffers count 0 Acumm rgba : 0 0 0 0 *** Amaya: Irrecoverable error ***Segmentation fault Can you get a backtrace for this? Nope. I can't even reproduce it. Maybe Andrea could do that ? If there is any more information I can provide that would help finding what's wrong, pleas edon't hesitate to ask. Thanks for your help, Regis #0 gdk_x_error (display=0x97b1948, error=0xafcc243c) at gdkmain-x11.c:599 #1 0xa6d2277f in _XError (dpy=0x97b1948, rep=0xafcc253c) at ../../src/XlibInt.c:2886 #2 0xa6d22d9f in _XReply (dpy=0x97b1948, rep=0xafcc253c, extra=0, discard=0) at ../../src/XlibInt.c:1815 #3 0xa7e4e73a in glXGetCurrentDrawable () from /usr/lib/libGL.so.1 #4 0xa7e4ea53 in glXMakeCurrentReadSGI () from /usr/lib/libGL.so.1 #5 0xa7e4ed63 in glXMakeCurrent () from /usr/lib/libGL.so.1 #6 0xa78e9128 in wxGLContext::SetCurrent () from /usr/lib/libwx_gtk2u_gl-2.6.so.0 #7 0xa78e9817 in wxGLCanvas::SetCurrent () from /usr/lib/libwx_gtk2u_gl-2.6.so.0 #8 0x082a0607 in wxDropTargetBase::OnLeave () #9 0x082a0a44 in wxDropTargetBase::OnLeave () #10 0xa77f2325 in wxAppConsole::HandleEvent () from /usr/lib/libwx_baseu-2.6.so.0 #11 0xa7882963 in wxEvtHandler::ProcessEventIfMatches () from /usr/lib/libwx_baseu-2.6.so.0 #12 0xa7882b6f in wxEventHashTable::HandleEvent () from /usr/lib/libwx_baseu-2.6.so.0 #13 0xa7882d4f in wxEvtHandler::ProcessEvent () from /usr/lib/libwx_baseu-2.6.so.0 #14 0xa78ea041 in wxGLCanvas::OnInternalIdle () from /usr/lib/libwx_gtk2u_gl-2.6.so.0 #15 0xa7ab2655 in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #16 0xa7ab268c in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #17 0xa7ab268c in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #18 0xa7ab268c in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #19 0xa7ab268c in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #20 0xa7ab268c in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #21 0xa7ab268c in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #22 0xa7ab268c in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #23 0xa7ab268c in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #24 0xa7ab2a19 in wxAppBase::ProcessIdle () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #25 0xa7a00e93 in wxApp::Yield () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #26 0xa67a7cc1 in g_idle_dispatch (source=0x9b42698, callback=0x97b1948, user_data=0x0) at gmain.c:3796 #27 0xa67a5691 in IA__g_main_context_dispatch (context=0x97a21f8) at gmain.c:1916 #28 0xa67a89d7 in g_main_context_iterate (context=0x97a21f8, block=1, dispatch=1, self=0x97a3090) at gmain.c:2547 #29 0xa67a9109 in IA__g_main_context_iteration (context=0x97a21f8, may_block=1) at gmain.c:2606 #30 0xa6b02a15 in IA__gtk_main_iteration () at gtkmain.c:1086 #31 0xa7a00b85 in wxApp::Yield () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #32 0xa78850cf in wxYield () from /usr/lib/libwx_baseu-2.6.so.0 #33 0x082171ae in wcstok () #34 0x0822da25 in wxMenuItemList::~wxMenuItemList () #35 0x08275c02 in wxDataObjectSimple::~wxDataObjectSimple () #36 0x080f944f in wxLogDebug () #37 0x080ff9f1 in wxLogDebug () #38 0x081019ee in wxLogDebug () #39 0x08101db2 in
Bug#362575: amaya: Two exploitable buffer overflows in Amaya
tags 362575 +pending thanks Hi, I have a package almost ready, just waiting for a redland bug to reach the pool. (It makes Amaya FTBFS) Regis Moritz Muehlenhoff said: Package: amaya Severity: grave Tags: security Justification: user security hole Two exploitable buffer overflows have been found in Amaya. Please see these URLs for details: http://morph3us.org/advisories/20060412-amaya-94.txt http://morph3us.org/advisories/20060412-amaya-94-2.txt Cheers, Moritz -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#357439: amaya does not start--The program 'amaya' received an X Window System error.
Ok, si this bug is now starting to turn me crazy. All running tests point to a problem with Mesa : -crash with Mesa in software mode -no crash with Mesa using the ATI DRI, but weird display of the web pages -no crash with the nvidia proprietary driver, display is happy. When I tried using gdb to get a backtrace(attached), all I got was a long list of calls involving wxWidgets, GTK, but not Mesa. CCing the XSF in case someone has an idea, or if this could be related to the Mesa/Xorg drivers problem, otherwise my next try will probably involve the sacrifice of a chicken. Regis On Wed, 2006-03-22 at 09:21 +0100, Andrea De Michele wrote: Hi Regis, May be the following can be useful: If I start amaya with a file name, like: ~$ amaya file.html the program starts correctly with file.html open. May be the problem is with the Welcome start page of amaya. In fact if I start simply amaya: ~$ amaya file.html I see for few second the amaya window with the file /usr/lib/amaya/amaya/AmayaPage_WX.html open, but i see strange changing of color on the screen and after few second the program crash. More strange: if during the few second of changing of color I scroll down the AmayaPage_WX.html page these changing of color stop and the program does not crash. Very strange! Anyway now I can use the program. Andrea. Il giorno mar, 21/03/2006 alle 14.47 +, Regis Boudin ha scritto: Hi Andrea, Andrea De Michele said: Hi Regis, I used ati driver without DRI. I do not use DRI because it give me some problem: when i switch console (CTRL+ALT+Fn) the system crash if DRI is loaded. Thanks for the additional informations. This tend to confirm my thoughts that the problem is OpenGL/Mesa related, but I'm not sure if the bug is in Amaya or the Mesa library. Anyway today I have tried amaya with DRI loaded and amaya crash with the following message: [EMAIL PROTECTED]:~$ amaya 09:22:28: Deleted stale lock file '/home/andrea/amaya-andrea'. OpenGL Status: Software Mode = Hard VENDOR : Tungsten Graphics, Inc. VERSION : 1.2 Mesa 6.4.1 RENDERER : Mesa DRI Radeon 20050528 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL GLU Version : 1.3 Aux buffers count 0 Acumm rgba : 0 0 0 0 *** Amaya: Irrecoverable error ***Segmentation fault Yay ! find where one of the problems is, get a new one ! Anyway, thanks for your help, Regis #0 gdk_x_error (display=0x97b1a28, error=0xafb6e13c) at gdkmain-x11.c:599 #1 0xa6aeb77f in _XError (dpy=0x97b1a28, rep=0xafb6e200) at ../../src/XlibInt.c:2886 #2 0xa6aebd9f in _XReply (dpy=0x97b1a28, rep=0xafb6e200, extra=0, discard=1) at ../../src/XlibInt.c:1815 #3 0xa6ae3275 in XSync (dpy=0x97b1a28, discard=0) at ../../src/Sync.c:48 #4 0xa6ae3323 in _XSyncFunction (dpy=0x97b1a28) at ../../src/Synchro.c:37 #5 0xa6aa9229 in XShmPutImage (dpy=0x97b1a28, d=159062568, gc=0x9d92b48, image=0x9d92a18, src_x=159062568, src_y=159062568, dst_x=159062568, dst_y=159062568, src_width=159062568, src_height=159062568, send_event=159062568) at ../../src/XShm.c:358 #6 0xa6769d98 in gdk_x11_draw_image (drawable=0xa8cb180, gc=0x97e8208, image=0x994e8c0, xsrc=0, ysrc=0, xdest=0, ydest=0, width=12, height=12) at gdkdrawable-x11.c:821 #7 0xa6742c6a in IA__gdk_draw_image (drawable=0xa8cb180, gc=0x97e8208, image=0x994e8c0, xsrc=159062568, ysrc=159062568, xdest=159062568, ydest=159062568, width=12, height=12) at gdkdraw.c:726 #8 0xa674dcbc in gdk_pixmap_draw_image (drawable=0x97b1a28, gc=0x97b1a28, image=0x97b1a28, xsrc=159062568, ysrc=159062568, xdest=159062568, ydest=159062568, width=159062568, height=159062568) at gdkpixmap.c:418 #9 0xa6742c6a in IA__gdk_draw_image (drawable=0xa1b9548, gc=0x97e8208, image=0x994e8c0, xsrc=159062568, ysrc=159062568, xdest=159062568, ydest=159062568, width=12, height=12) at gdkdraw.c:726 #10 0xa70764fe in wxBitmap::CreateFromImageAsPixmap () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #11 0xa70770cc in wxBitmap::CreateFromImage () from /usr/lib/libwx_gtk2u_core-2.6.so.0 #12 0xa7367080 in wxXmlResourceHandler::GetBitmap () from /usr/lib/libwx_gtk2u_xrc-2.6.so.0 #13 0xa73217eb in wxBitmapButtonXmlHandler::DoCreateResource () from /usr/lib/libwx_gtk2u_xrc-2.6.so.0 #14 0xa7364401 in wxXmlResourceHandler::CreateResource () from /usr/lib/libwx_gtk2u_xrc-2.6.so.0 #15 0xa7364e3d in wxXmlResource::CreateResFromNode () from /usr/lib/libwx_gtk2u_xrc-2.6.so.0 #16 0xa736518e in wxXmlResourceHandler::CreateChildren () from /usr/lib/libwx_gtk2u_xrc-2.6.so.0 #17 0xa7341107 in wxPanelXmlHandler::DoCreateResource () from /usr/lib/libwx_gtk2u_xrc-2.6.so.0 #18 0xa7364401 in wxXmlResourceHandler::CreateResource () from /usr/lib/libwx_gtk2u_xrc-2.6.so.0 #19 0xa7364e3d in wxXmlResource::CreateResFromNode () from /usr/lib/libwx_gtk2u_xrc-2.6.so.0 #20 0xa734a529 in wxSizerXmlHandler::Handle_sizeritem () from /usr/lib
Bug#364673: Should depend on libdb4.3-dev
Package: librdf0-dev Version: 1.0.3-6 Severity: serious Hi, The rdf library is linked against libdb4.3, but the librdf0-dev doesn't depend on libdb4.3-dev. This leads to FTBFS for packages trying to link against librdf, as redland-config --libs return -ldb4.3 and the /usr/lib/librdf.la file references libdb4.3 as well. Adding a dependency on libdb4.3-dev to librdf0-dev should fix the problem. I guess the problem didn't appear before because libdb4.3 was pulled by perl. Regards, Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357439: amaya does not start--The program 'amaya' received an X Window System error.
Hi Andrea, Andrea De Michele said: Hi Regis, May be the following can be useful: If I start amaya with a file name, like: ~$ amaya file.html the program starts correctly with file.html open. May be the problem is with the Welcome start page of amaya. In fact if I start simply amaya: ~$ amaya file.html I see for few second the amaya window with the file /usr/lib/amaya/amaya/AmayaPage_WX.html open, but i see strange changing of color on the screen and after few second the program crash. More strange: if during the few second of changing of color I scroll down the AmayaPage_WX.html page these changing of color stop and the program does not crash. That's very intersting indeed. Very strange! Well, at least it is consistent with the fact that the error looks OpenGL related. At the start of this page, there is an SVG logo of Amaya, which seems to ber rendered using OpenGL. So, if Anyway now I can use the program. Good to know :) I will try to prepare an alternative starting page with a warning message about this problem, so users can at least start and use Amaya, despite what seems to be an SVG rendering problem. Many thanks for your help. Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#357439: amaya does not start--The program 'amaya' received an X Window System error.
Hi Andrea, Andrea De Michele said: Hi Regis, I used ati driver without DRI. I do not use DRI because it give me some problem: when i switch console (CTRL+ALT+Fn) the system crash if DRI is loaded. Thanks for the additional informations. This tend to confirm my thoughts that the problem is OpenGL/Mesa related, but I'm not sure if the bug is in Amaya or the Mesa library. Anyway today I have tried amaya with DRI loaded and amaya crash with the following message: [EMAIL PROTECTED]:~$ amaya 09:22:28: Deleted stale lock file '/home/andrea/amaya-andrea'. OpenGL Status: Software Mode = Hard VENDOR : Tungsten Graphics, Inc. VERSION : 1.2 Mesa 6.4.1 RENDERER : Mesa DRI Radeon 20050528 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL GLU Version : 1.3 Aux buffers count 0 Acumm rgba : 0 0 0 0 *** Amaya: Irrecoverable error ***Segmentation fault Yay ! find where one of the problems is, get a new one ! Anyway, thanks for your help, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#357439: amaya does not start--The program 'amaya' received an X Window System error.
Hi Andrea, After a kernel update making amaya crash and further tests, I tend more and more to think the problem comes from the use of Mesa. Could you please let me know you configuration, especially : -which video driver you use -if you use the DRI For the record, in my case : -with the nvidia proprietary driver, no problem -with the radeon driver and DRI, it run with display bugs -with the radeon driver but no DRI, it crashes. I will continue investigating the problem... Regis On Fri, 2006-03-17 at 12:53 +, Regis Boudin wrote: tags 357439 +confirmed thanks Hi, This is a known problem, which appears on some machines but not some others, depending on... Well, nobody seems to actually know what's wrong. Thanks for the report. Regis Andrea De Michele said: Package: amaya Version: 9.4-2 Severity: grave Justification: renders package unusable amaya does not start. I received the following error message: The program 'amaya' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 20807 error_code 8 request_code 144 minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages amaya depends on: ii libc6 2.3.6-3GNU C Library: Shared libraries an ii libcomerr21.38+1.39-WIP-2005.12.31-1 common error description library ii libcurl3 7.15.2-3 Multi-protocol file transfer libra ii libdb4.3 4.3.29-5 Berkeley v4.3 Database Libraries [ ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.3-1 GCC support library ii libglu1-xorg 6.9.0.dfsg.1-4 Mesa OpenGL utility library [X.Org ii libidn11 0.5.18-2 GNU libidn library, implementation ii libjpeg62 6b-12 The Independent JPEG Group's JPEG ii libkrb53 1.4.3-6MIT Kerberos runtime libraries ii libmysqlclien 5.0.18-9 mysql database client library ii libpng12-01.2.8rel-5 PNG library - runtime ii libraptor11.4.8-3Raptor RDF parser and serializer l ii librasqal00.9.11-1 Rasqal RDF query library ii librdf0 1.0.2-2.1 Redland Resource Description Frame ii libsqlite3-0 3.2.8-1SQLite 3 shared library ii libssl0.9.8 0.9.8a-7 SSL shared libraries ii libstdc++64.0.3-1The GNU Standard C++ Library v3 ii libwxgtk2.6-0 2.6.1.2wxWidgets Cross-platform C++ GUI t ii libxml2 2.6.23.dfsg.2-2GNOME XML library ii libxslt1.11.1.15-4 XSLT processing library - runtime ii xlibmesa-gl [ 6.9.0.dfsg.1-4 Mesa 3D graphics library [X.Org] ii zlib1g1:1.2.3-11 compression library - runtime amaya recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357439: amaya does not start--The program 'amaya' received an X Window System error.
tags 357439 +confirmed thanks Hi, This is a known problem, which appears on some machines but not some others, depending on... Well, nobody seems to actually know what's wrong. Thanks for the report. Regis Andrea De Michele said: Package: amaya Version: 9.4-2 Severity: grave Justification: renders package unusable amaya does not start. I received the following error message: The program 'amaya' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 20807 error_code 8 request_code 144 minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages amaya depends on: ii libc6 2.3.6-3GNU C Library: Shared libraries an ii libcomerr21.38+1.39-WIP-2005.12.31-1 common error description library ii libcurl3 7.15.2-3 Multi-protocol file transfer libra ii libdb4.3 4.3.29-5 Berkeley v4.3 Database Libraries [ ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.3-1 GCC support library ii libglu1-xorg 6.9.0.dfsg.1-4 Mesa OpenGL utility library [X.Org ii libidn11 0.5.18-2 GNU libidn library, implementation ii libjpeg62 6b-12 The Independent JPEG Group's JPEG ii libkrb53 1.4.3-6MIT Kerberos runtime libraries ii libmysqlclien 5.0.18-9 mysql database client library ii libpng12-01.2.8rel-5 PNG library - runtime ii libraptor11.4.8-3Raptor RDF parser and serializer l ii librasqal00.9.11-1 Rasqal RDF query library ii librdf0 1.0.2-2.1 Redland Resource Description Frame ii libsqlite3-0 3.2.8-1SQLite 3 shared library ii libssl0.9.8 0.9.8a-7 SSL shared libraries ii libstdc++64.0.3-1The GNU Standard C++ Library v3 ii libwxgtk2.6-0 2.6.1.2wxWidgets Cross-platform C++ GUI t ii libxml2 2.6.23.dfsg.2-2GNOME XML library ii libxslt1.11.1.15-4 XSLT processing library - runtime ii xlibmesa-gl [ 6.9.0.dfsg.1-4 Mesa 3D graphics library [X.Org] ii zlib1g1:1.2.3-11 compression library - runtime amaya recommends no packages. -- no debconf information -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#348706: amaya: Something similar on 9.4-1
Hi, Thanks for the information. This problem seems to come from upstream, as I've seen reports of the same problems from users of Gentoo/Fedora/Ubuntu, sometimes triggered by an update of Xorg. Unfortunately, I can't reproduce the error on my systems, but will definitely try to find what is wrong. Regis xdrudis said: FWIW: I grabbed an earlier version, amaya_9.2.1-6_i386.deb from a friend's computer /var/cache/apt/archives (I didn't find it online) and it works on the same system where 9.4-1 doesn't. -- - jo també vull una Europa lliure de patents de programari - -- EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es -- http://patents.caliu.info Xavi Drudis Ferran [EMAIL PROTECTED] -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#355090: FTBFS: error: cast from 'void*' to 'int' loses precision
tags 355063 +pending tags 355090 +pending thanks Hi, Having finally found a 64 bits machine to test, I now have a patch for this bug. Thanks for the report. Regis Roberto Pariset said: Package: amaya Version: 9.4-1 Severity: serious Justification: fails to build from source Hi, amaya 9.4-1 FTBFS on 64 bit archs because of the following problem: [...] x86_64-linux-gnu-g++ -O2 -Wall -x c++ -D__cplusplus -D_UNIX -D_GL -D_WX -DHAVE_CONFIG_H -I.. -I../../amaya/xpm -I../../thotlib/include -I../../thotlib/internals/var -I../../thotlib/internals/h -I../../thotlib/internals/f-I/build/buildd/amaya-9.4/wxWidgets/src/png -I/build/buildd/amaya-9.4/wxWidgets/src/jpeg -I/build/buildd/amaya-9.4/wxWidgets/src/tiff -I/build/buildd/amaya-9.4/Amaya/WX/wxWidgets_RELEASE/lib/wx/include/gtk2-unicode-release-static-2.6 -I/build/buildd/amaya-9.4/wxWidgets/include -I/build/buildd/amaya-9.4/wxWidgets/contrib/include -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -DNO_GCC_PRAGMA -I/usr/include/freetype2 -c ../../thotlib/dialogue/AmayaXMLPanel.cpp -o dialogue/AmayaXMLPanel.o ../../thotlib/dialogue/AmayaXMLPanel.cpp: In member function 'virtual void AmayaXMLPanel::SendDataToPanel(AmayaParams)': ../../thotlib/dialogue/AmayaXMLPanel.cpp:105: error: cast from 'void*' to 'int' loses precision make[2]: *** [dialogue/AmayaXMLPanel.o] Error 1 make[2]: Leaving directory `/build/buildd/amaya-9.4/Amaya/WX/thotlib' make[1]: *** [thotlib] Error 2 make[1]: Leaving directory `/build/buildd/amaya-9.4/Amaya/WX' make: *** [build-arch-stamp] Error 2 Thanks, Roberto -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) (ignored: LC_ALL set to [EMAIL PROTECTED]) -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#354766: rdf_log.h should include raptor.h
Hi Dave, Dave Beckett said: To fix this, I suppose rdf_log.h should include raptor.h You should never include rdf_log.h directly, always #include redland.h which pulls in raptor.h there. Just for the record, the code isn't mine, but comes from Amaya (the browser), which includes librdf.h (not rdf_log.h). I will report that and propose a patch using redland.h to the Amaya upstream. However, I still find quite strange for a header file to rely on the including file to call another header before and would personally consider it as a bug if it was in my software. Anyway, if you decide to close this bug, I won't complain or reopen it. Thanks for the quick answer. Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#354766: rdf_log.h should include raptor.h
Package: librdf0-dev Version: 1.0.2-2 Severity: grave Hi, Trying to build Amaya using the system librdf fails because the raptor_locator type is not defined in rdf_log.h To fix this, I suppose rdf_log.h should include raptor.h Regards, Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346632: ITNMU
Hi, Is there someone around to upload a fixed package or sponsor a NMU ? There is a source package at http://www.imalip.info/amaya/9.2.1-6.1/ with the attached patch applied, and the following new changelog entry : 8- amaya (9.2.1-6.1) unstable; urgency=low * NMU for xlibs-dev transition + Replace xlibs-dev build-dependency by libxt-dev, libx11-dev, libxinerama-dev and libxxf86vm-dev (Closes: #346632) * Build-depend on libfreetype6-dev. (Closes: #340289) * Pass --with-gl option when running configure script. This makes the amaya binary link against the system-provided libGL and libGLU instead of building Mesa and linking against the built lib. (Closes: #348706, #348705) * Pass --disable-rpath option when configuring wxWidgets. With the previous change, there is no more rpath set. (Closes: #341424) * When calling make, set the HOME environment variable to the build directory, so tools can safely write in it. (Closes: #336014) * Apply a patch stolen from upstream CVS to wxWidgets/src/gtk/window.cpp, wxWidgets can build against GTK+ 2.8. * Remove debian/amaya.doc-base.EX and add debian/amaya.links, fixing 2 lintian warnings. 8- Also, I am a bit of a masochist, so I packaged amaya 9.3. I will try to make the package available tomorrow evening, if anyone is interested. HTH, Regis On Fri, 2006-01-13 at 10:04 +0100, Amaya wrote: Anand Kumria wrote: Hmm -- it compiled before, so you seem to have a interesting version of libpango Isn't it cool to realize pbuilder was pointing to testing for some wicked reason? I am full of joy. Unless you are a masochist, you don't want to be touching a new upstream. I slightly tried and realized I am not enough of a masochist, and also there is plenty of work to do... I am going to try to fix my pbuilder setup and give it a run. I'll keep you updated on this. (I still want to do this. Just because it is recursive and cute and wiked and schizophreniac) LOL diff -urN -x changelog amaya-9.2.1-6/Amaya/configure amaya-9.2.1-6.1/Amaya/configure --- amaya-9.2.1-6/Amaya/configure 2005-08-13 01:29:25.0 +0100 +++ amaya-9.2.1-6.1/Amaya/configure 2006-01-31 23:01:36.255538552 + @@ -13703,7 +13703,7 @@ # --enable-unicodecompile wxString with Unicode support # --with-gtk use GTK+ # --with-opengl use OpenGL (or Mesa) -WXCONFIGURE_OPTION=--with-opengl --with-gtk --enable-gtk2 --enable-unicode --enable-ipc --disable-shared --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin $WXCONFIGURE_TUNNING_OPTION +WXCONFIGURE_OPTION=--with-opengl --with-gtk --enable-gtk2 --enable-unicode --enable-ipc --disable-shared --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin $WXCONFIGURE_TUNNING_OPTION --disable-rpath fi if test $AMAYAOS = MACOSX ; then # MACOSX diff -urN -x changelog amaya-9.2.1-6/debian/amaya.doc-base.EX amaya-9.2.1-6.1/debian/amaya.doc-base.EX --- amaya-9.2.1-6/debian/amaya.doc-base.EX 2006-01-31 22:57:38.733647368 + +++ amaya-9.2.1-6.1/debian/amaya.doc-base.EX 1970-01-01 01:00:00.0 +0100 @@ -1,22 +0,0 @@ -Document: amaya -Title: Debian amaya Manual -Author: insert document author here -Abstract: This manual describes what amaya is - and how it can be used to - manage online manuals on Debian systems. -Section: unknown - -Format: debiandoc-sgml -Files: /usr/share/doc/amaya/amaya.sgml.gz - -Format: postscript -Files: /usr/share/doc/amaya/amaya.ps.gz - -Format: text -Files: /usr/share/doc/amaya/amaya.text.gz - -Format: HTML -Index: /usr/share/doc/amaya/html/index.html -Files: /usr/share/doc/amaya/html/*.html - - diff -urN -x changelog amaya-9.2.1-6/debian/amaya.links amaya-9.2.1-6.1/debian/amaya.links --- amaya-9.2.1-6/debian/amaya.links 1970-01-01 01:00:00.0 +0100 +++ amaya-9.2.1-6.1/debian/amaya.links 2006-01-31 23:01:36.647478968 + @@ -0,0 +1 @@ +usr/share/man/man1/amaya.1 usr/share/man/man1/amaya-wx.1 diff -urN -x changelog amaya-9.2.1-6/debian/control amaya-9.2.1-6.1/debian/control --- amaya-9.2.1-6/debian/control 2006-01-31 22:57:38.736646912 + +++ amaya-9.2.1-6.1/debian/control 2006-01-31 23:01:36.648478816 + @@ -2,7 +2,7 @@ Section: web Priority: optional Maintainer: Anand Kumria [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.0.0), automake1.7, libgtk2.0-dev, libpng12-dev, libjpeg62-dev, xlibs-dev ( 4.1.0), libglu1-xorg-dev, xutils +Build-Depends: debhelper (= 4.0.0), automake1.7, libgtk2.0-dev, libpng12-dev, libjpeg62-dev, libglu1-xorg-dev, libxt-dev, , libx11-dev, libxinerama-dev, libxxf86vm-dev, libfreetype6-dev, xutils Standards-Version: 3.6.2.1 Package: amaya diff -urN -x changelog amaya-9.2.1-6/debian/rules amaya-9.2.1-6.1/debian/rules --- amaya-9.2.1-6/debian/rules 2006-01-31 22:57:38.737646760 + +++ amaya-9.2.1-6.1/debian/rules 2006-01-31
Bug#350066: Tellico FTBS, libkcal.la references libXft.la which does not exist anymore
Package: kdepim Version: 3.5.0-5 Severity: grave Hi, Trying to build a snapshot of tellico, it FTBS because of a missing /usr/lib/libXft.la file. I tried to rebuild the latest version of tellico with pbuilder, which also failed with the same error. All the .la files from the kdepim dev packages reference /usr/lib/libXft.la, if the build was done with libxft-dev 2.1.8. However, the file was removed last week with xft 2.1.8.2-1, making the packages linking against any of the kdepim libs FTBFS, hence the grave severity. i386 if affected, but some arches are not, such as i64. I tried rebuilding kdepim and installing the generated packages, and I could successfully build tellico. I am not sure if the solution is to rebuild kdepim with the new xft, or include libXft.la back, so I CC the xft maintainer, but something needs to be done. Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348706: There could be a simpler patch
Hi, having thought about it since yesterday evening and checked this morning in the upstream configure.in file, it looks like passing the --with-gl flag when calling configure would be enought to fix this bug. However, I can't test it before this evening, but I will do it and give the result as soon as I can. Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#348706: Possible patch
On Wed, 2006-01-25 at 16:49 +0100, Amaya wrote:
Regis Boudin wrote:
It looks like the problem is due to the Mesa part. Applying the
attached patch, amaya was linked against the Xorg shared library
during the build instead of the internally provided one.
Forgot to attach the patch maybe? :)
Oups :P
Well, it doesn't matter much, it was not the best way... Attached this
time is one passing the --with-gl flag to configure, so it links against
the system-provided libGLU instead of the included source.
Also attached, a cumulative patch, which should close #341424, #348706,
#336014, #346632, #340289, and #348705. (is that enough ?)
Thanks for everything, you rock!
Thank you for your work, too.
By the way, for information, my mail server rejected your mail, it looks
like there is no reverse DNS entry for our IP adress.
Thanks
Regis
--
While a monkey can be a manager, it takes a human to be an engineer
Erik Zapletal
diff -urN amaya-9.2.1/debian/rules amaya-9.2.1.gl/debian/rules
--- amaya-9.2.1/debian/rules 2006-01-25 18:57:16.476609560 +
+++ amaya-9.2.1.gl/debian/rules 2006-01-25 18:59:52.628870808 +
@@ -40,7 +40,7 @@
# Add here commands to configure the package.
mkdir -p Amaya/WX
cd Amaya/WX \
- ../configure --prefix=/usr --with-wx --with-dav \
+ ../configure --prefix=/usr --with-wx --with-gl --with-dav \
--enable-offical-build \
cd ../..
# --libpng, libjpeg, libtiff (currently builtin)
diff -urN amaya-9.2.1/Amaya/configure amaya-9.2.1.gl/Amaya/configure
--- amaya-9.2.1/Amaya/configure 2005-08-13 01:29:25.0 +0100
+++ amaya-9.2.1.gl/Amaya/configure 2006-01-25 19:01:07.001564440 +
@@ -13642,7 +13642,7 @@
# this is the flags used to build amaya with OpenGL
GL_OPTIONS=-D_GL
GL_INCLUDES=-I${GL_BUILDDIR}/include
- GL_LIBRARIES=-Wl,-rpath,${GL_BUILDDIR}/lib -L${GL_BUILDDIR}/lib -lGL -lGLU
+ GL_LIBRARIES=-L${GL_BUILDDIR}/lib -lGL -lGLU
@@ -13703,7 +13703,7 @@
# --enable-unicodecompile wxString with Unicode support
# --with-gtk use GTK+
# --with-opengl use OpenGL (or Mesa)
-WXCONFIGURE_OPTION=--with-opengl --with-gtk --enable-gtk2 --enable-unicode --enable-ipc --disable-shared --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin $WXCONFIGURE_TUNNING_OPTION
+WXCONFIGURE_OPTION=--with-opengl --with-gtk --enable-gtk2 --enable-unicode --enable-ipc --disable-shared --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin $WXCONFIGURE_TUNNING_OPTION --disable-rpath
fi
if test $AMAYAOS = MACOSX ; then
# MACOSX
diff -urN amaya-9.2.1/debian/control amaya-9.2.1.gl/debian/control
--- amaya-9.2.1/debian/control 2006-01-25 18:57:16.470610472 +
+++ amaya-9.2.1.gl/debian/control 2006-01-25 19:01:19.517661704 +
@@ -2,7 +2,7 @@
Section: web
Priority: optional
Maintainer: Anand Kumria [EMAIL PROTECTED]
-Build-Depends: debhelper (= 4.0.0), automake1.7, libgtk2.0-dev, libpng12-dev, libjpeg62-dev, xlibs-dev ( 4.1.0), libglu1-xorg-dev, xutils
+Build-Depends: debhelper (= 4.0.0), automake1.7, libgtk2.0-dev, libpng12-dev, libjpeg62-dev, libglu1-xorg-dev, libxt-dev, libxxf86vm-dev, libfreetype6-dev, xutils
Standards-Version: 3.6.2.1
Package: amaya
diff -urN amaya-9.2.1/debian/rules amaya-9.2.1.gl/debian/rules
--- amaya-9.2.1/debian/rules 2006-01-25 18:57:16.476609560 +
+++ amaya-9.2.1.gl/debian/rules 2006-01-25 19:01:03.005171984 +
@@ -40,7 +40,7 @@
# Add here commands to configure the package.
mkdir -p Amaya/WX
cd Amaya/WX \
- ../configure --prefix=/usr --with-wx --with-dav \
+ ../configure --prefix=/usr --with-wx --with-gl --with-dav \
--enable-offical-build \
cd ../..
# --libpng, libjpeg, libtiff (currently builtin)
@@ -58,7 +58,7 @@
# Add here commands to compile the arch part of the package.
cd Amaya/WX \
- $(MAKE) CFLAGS=$(CFLAGS) \
+ HOME=$(CURDIR)/Amaya/WX $(MAKE) CFLAGS=$(CFLAGS) \
cd ../..
touch build-arch-stamp
diff -urN amaya-9.2.1/wxWidgets/src/gtk/window.cpp amaya-9.2.1.gl/wxWidgets/src/gtk/window.cpp
--- amaya-9.2.1/wxWidgets/src/gtk/window.cpp 2005-08-13 01:29:47.0 +0100
+++ amaya-9.2.1.gl/wxWidgets/src/gtk/window.cpp 2006-01-25 19:01:15.519269552 +
@@ -4280,12 +4280,10 @@
return gtk_widget_get_pango_context( m_widget );
}
+// MR: Returns the same as GtkGetPangoDefaultContext until the symbol can be removed in 2.7.x
PangoContext *wxWindowGTK::GtkGetPangoX11Context()
{
-if (!m_x11Context)
-m_x11Context = pango_x_get_context( gdk_display );
-
-return m_x11Context;
+return gtk_widget_get_pango_context( m_widget );
}
#endif
Bug#269534: package removed from sid
Hi, Considering cursel has been removed from sid, shouldn't these bugs be closed ? Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#348706: Possible patch
tags 348706 +patch thanks Hi, Continuing my amaya bug squashing. It looks like the problem is due to the Mesa part. Applying the attached patch, amaya was linked against the Xorg shared library during the build instead of the internally provided one. Note this patch also includes the one getting rid of the rpath complaint from lintian, as it affects the configure file. Hopefully, with the other patches I already submitted, the amaya package will now be in a good enough shape to be uploaded. Applying them, I could successfully build the package with pbuilder, install it and run it. Regards Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277018: Bug should be closed
Hi, Is there any reason why this bug should be kept open, considering sarge has been released ? I suggest it should be closed. Regards, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#272004:
Hi, Looking at the changelog and versions history, it looks like libtunepimp 0.3.0-test2-1 was actually a mis-numbered pre-0.3.0 snapshot, which was expected to be superseded by 0.3.0-1. Therefore, I suggest to remove the version from experimental and close this bug. HTH, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#336014: possible patch
tags 336014 +patch thanks Hi, Find attached a patch setting the HOME directory to Amaya/WX directory when calling make. This means that the .amaya directory is created in the build directory instead the original /home and should fix the bug. At least I could build in a chrooted environment with the original home directory set as read-only. HTH, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal --- amaya-9.2.1/debian/rules 2006-01-22 19:52:10.079248560 + +++ amaya-9.2.1.ok/debian/rules 2006-01-23 23:12:17.788926424 + @@ -58,7 +58,7 @@ # Add here commands to compile the arch part of the package. cd Amaya/WX \ - $(MAKE) CFLAGS=$(CFLAGS) \ + HOME=$(CURDIR)/Amaya/WX $(MAKE) CFLAGS=$(CFLAGS) \ cd ../.. touch build-arch-stamp
Bug#346632: A couple of patches.
tags 340289 +patch
tags 346632 +patch
thanks
Hi again.
The pango problem is actually a wxWidgets bug with GTK+ 2.8. Please find
attached a patch fixing it, stolen from CVS (and the wxwidgets2.6
package).
Also attached a patch replacing the xlibs-dev Build-Depends by libxt-dev
and libxxf86vm-dev, as well as libfreetype6-dev, which should fix
#340289.
Applying both patched, I could succesfully rebuild amaya with pbuilder.
I also started looking at #336014.
Please don't hesitate to contact me.
Regards,
Regis
--
While a monkey can be a manager, it takes a human to be an engineer
Erik Zapletal
--- amaya-9.2.1/wxWidgets/src/gtk/window.cpp 2005-08-13 01:29:47.0 +0100
+++ amaya-9.2.1.ok/wxWidgets/src/gtk/window.cpp 2006-01-22 22:53:42.117407072 +
@@ -4280,12 +4280,10 @@
return gtk_widget_get_pango_context( m_widget );
}
+// MR: Returns the same as GtkGetPangoDefaultContext until the symbol can be removed in 2.7.x
PangoContext *wxWindowGTK::GtkGetPangoX11Context()
{
-if (!m_x11Context)
-m_x11Context = pango_x_get_context( gdk_display );
-
-return m_x11Context;
+return gtk_widget_get_pango_context( m_widget );
}
#endif
--- amaya-9.2.1.o/debian/control 2006-01-20 18:34:12.323142864 +
+++ amaya-9.2.1.xd/debian/control 2006-01-21 23:24:25.665718576 +
@@ -2,7 +2,7 @@
Section: web
Priority: optional
Maintainer: Anand Kumria [EMAIL PROTECTED]
-Build-Depends: debhelper (= 4.0.0), automake1.7, libgtk2.0-dev, libpng12-dev, libjpeg62-dev, xlibs-dev ( 4.1.0), libglu1-xorg-dev, xutils
+Build-Depends: debhelper (= 4.0.0), automake1.7, libgtk2.0-dev, libpng12-dev, libjpeg62-dev, libglu1-xorg-dev, libxt-dev, libxxf86vm-dev, libfreetype6-dev, xutils
Standards-Version: 3.6.2.1
Package: amaya
Bug#341424: The previous patch was wrong
Hi again,
The previous patch is buggy, and it won't even build.
Tha new attached one actually works.
Regis
--
While a monkey can be a manager, it takes a human to be an engineer
Erik Zapletal
diff -urN amaya-9.2.1.o/Amaya/configure amaya-9.2.1/Amaya/configure
--- amaya-9.2.1.o/Amaya/configure 2005-08-13 01:29:25.0 +0100
+++ amaya-9.2.1/Amaya/configure 2006-01-20 18:48:29.381850136 +
@@ -13642,7 +13642,7 @@
# this is the flags used to build amaya with OpenGL
GL_OPTIONS=-D_GL
GL_INCLUDES=-I${GL_BUILDDIR}/include
- GL_LIBRARIES=-Wl,-rpath,${GL_BUILDDIR}/lib -L${GL_BUILDDIR}/lib -lGL -lGLU
+ GL_LIBRARIES=-L${GL_BUILDDIR}/lib -lGL -lGLU
@@ -13703,7 +13703,7 @@
# --enable-unicodecompile wxString with Unicode support
# --with-gtk use GTK+
# --with-opengl use OpenGL (or Mesa)
-WXCONFIGURE_OPTION=--with-opengl --with-gtk --enable-gtk2 --enable-unicode --enable-ipc --disable-shared --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin $WXCONFIGURE_TUNNING_OPTION
+WXCONFIGURE_OPTION=--with-opengl --with-gtk --enable-gtk2 --enable-unicode --enable-ipc --disable-shared --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin $WXCONFIGURE_TUNNING_OPTION --disable-rpath
fi
if test $AMAYAOS = MACOSX ; then
# MACOSX
Bug#341424: Patch offer
tags 341424 +patch
thanks
Hi,
Please find attached a patch, which :
-adds the --disable-rpath flag when configuring wxWidgets
-removes the rpath option from the GL_LIBRARIES variable.
Applying it, I rebuilt the package and lintian stopped complaining about
rpath.
HTH,
Regis
--
While a monkey can be a manager, it takes a human to be an engineer
Erik Zapletal
diff -urN amaya-9.2.1.o/Amaya/configure amaya-9.2.1/Amaya/configure
--- amaya-9.2.1.o/Amaya/configure 2005-08-13 01:29:25.0 +0100
+++ amaya-9.2.1/Amaya/configure 2006-01-20 18:48:29.381850136 +
@@ -13642,7 +13642,7 @@
# this is the flags used to build amaya with OpenGL
GL_OPTIONS=-D_GL
GL_INCLUDES=-I${GL_BUILDDIR}/include
- GL_LIBRARIES=-Wl,-rpath,${GL_BUILDDIR}/lib -L${GL_BUILDDIR}/lib -lGL -lGLU
+ GL_LIBRARIES=-Wl,${GL_BUILDDIR}/lib -L${GL_BUILDDIR}/lib -lGL -lGLU
@@ -13703,7 +13703,7 @@
# --enable-unicodecompile wxString with Unicode support
# --with-gtk use GTK+
# --with-opengl use OpenGL (or Mesa)
-WXCONFIGURE_OPTION=--with-opengl --with-gtk --enable-gtk2 --enable-unicode --enable-ipc --disable-shared --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin $WXCONFIGURE_TUNNING_OPTION
+WXCONFIGURE_OPTION=--with-opengl --with-gtk --enable-gtk2 --enable-unicode --enable-ipc --disable-shared --with-libpng=builtin --with-libjpeg=builtin --with-libtiff=builtin $WXCONFIGURE_TUNNING_OPTION --disable-rpath
fi
if test $AMAYAOS = MACOSX ; then
# MACOSX
Bug#347475: Patch proposal
tags 347475 + patch thanks Hi Amaya, I managed to reproduce the bug with pbuilder and found a fix. The problem is that the detection the X11 directory is based on the detection of libXt. Adding libxt-dev to the build-dependencies means the configure script can find where to get the X11 lib. Se patch attached. Regards, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal --- fkiss-0.33a.patch/debian/control 2006-01-13 22:50:30.536318080 + +++ fkiss-0.33a.patch.patched/debian/control 2006-01-13 22:47:27.318171000 + @@ -2,7 +2,7 @@ Section: games Priority: optional Maintainer: Amaya Rodrigo Sastre [EMAIL PROTECTED] -Build-Depends: debhelper (=4), autotools-dev, automake, libx11-dev, x-dev +Build-Depends: debhelper (=4), autotools-dev, automake, libx11-dev, libxt-dev Standards-Version: 3.6.2.0 Package: fkiss
Bug#328009: tellico: uninstallable; needs rebuild for the Qt/KDE transition
merge 328009 326850 thanks Hi, I already know about it, and I have a couple of issues : -tellico build-depends on kdemultimedia-dev which is not built on m68k yet -I am not yet a DD, so I need a sponsor to upload. Plus, a new version, which build-depends on kdepim-dev has been released, and kdepim FTBFS on arm/hppa/m68k. So, rather than a NMU on this outdated version, I would much prefer a sponsoring of the new one. The package is ready, I only need to make the source available. I will follow-up on this mail later today, with the adresse to get it from, for anyone who would like to help. Regards, Regis - a bit frustrated to see an accumulation of bugs just because I can't upload this bloody package Adeodato Simó said: Package: tellico Version: 0.13.3-1 Severity: grave Tags: sid Hello, This is a grave bug filed against your package because it depends on libqt3c102-mt, which no longer exists, thus rendering yor package uninstallable in unstable. As part of the C++ ABI transition, this library has moved to the libqt3-mt package. Simply recompiling and uploading your package should be enough to fix this; as per this mail [1], you need not bump your Qt, kdelibs or aRts build-dependencies. Beware, though, that that may not be the case for all the involved librares. Also, make sure that you build the package in an up to date and clean sid environment, so that final dependencies are correct. Please do this as soon as possible in order to accelerate the Qt/KDE transition to testing. [1] http://lists.debian.org/debian-devel-announce/2005/09/msg0.html Perhaps you find that your package fails to compile with gcc4. If that's the case, there's probably a bug about it in the BTS, and it may include a patch. If not (or if you have doubts about the correctness of the patch), you may be able to find a fix in upstream's CVS, or in the Ubuntu distribution. If your package fails only in arm, m68k, and hppa, see instructions in the above mail. Finally, if there's a strong reason for which your package should not be NMUed, please note so in this bug report. Prospective NMUers will read your reasoning, and will decide if it's strong enough to delay their upload. Thanks for your cooperation, and happy hacking! P.S.: There may be an already reported bug against this package for this very same reason. I've checked for that, and will be merging the bugs soon. The reason for still filing this bug was to have the opportunity of including the small bits of information above. I apologize for the inconvenience. -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#328009: tellico: uninstallable; needs rebuild for the Qt/KDE transition
Hi again, So, as promised earlier this morning, the latest tellico source package is at http://www.imalip.info/tellico/sid/source The upstream site is http://periapsis.org/tellico/ which show the same md5sum for the original source archive as the .orig.tar.gz If someone wants to sponsor this upload before kdepim, I won't fight for it before kdepim FTBFS is fixed. Regis On Tue, 2005-09-13 at 01:47 +0200, Adeodato Simó wrote: Package: tellico Version: 0.13.3-1 Severity: grave Tags: sid Hello, This is a grave bug filed against your package because it depends on libqt3c102-mt, which no longer exists, thus rendering yor package uninstallable in unstable. As part of the C++ ABI transition, this library has moved to the libqt3-mt package. Simply recompiling and uploading your package should be enough to fix this; as per this mail [1], you need not bump your Qt, kdelibs or aRts build-dependencies. Beware, though, that that may not be the case for all the involved librares. Also, make sure that you build the package in an up to date and clean sid environment, so that final dependencies are correct. Please do this as soon as possible in order to accelerate the Qt/KDE transition to testing. [1] http://lists.debian.org/debian-devel-announce/2005/09/msg0.html Perhaps you find that your package fails to compile with gcc4. If that's the case, there's probably a bug about it in the BTS, and it may include a patch. If not (or if you have doubts about the correctness of the patch), you may be able to find a fix in upstream's CVS, or in the Ubuntu distribution. If your package fails only in arm, m68k, and hppa, see instructions in the above mail. Finally, if there's a strong reason for which your package should not be NMUed, please note so in this bug report. Prospective NMUers will read your reasoning, and will decide if it's strong enough to delay their upload. Thanks for your cooperation, and happy hacking! P.S.: There may be an already reported bug against this package for this very same reason. I've checked for that, and will be merging the bugs soon. The reason for still filing this bug was to have the opportunity of including the small bits of information above. I apologize for the inconvenience. -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#327594: kdepim FTBFS on arm, hppa, m68k. should use gcc-3.4 on these arch
Package: kdepim Severity: serious Hi, kdepim FTBFS on the 3 arch with the usual internal compiler error : http://buildd.debian.org/fetch.php?pkg=kdepimver=4% 3A3.4.2-1arch=hppastamp=1125769502file=logas=raw http://buildd.debian.org/fetch.php?pkg=kdepimver=4% 3A3.4.2-1arch=armstamp=1125702059file=logas=raw http://buildd.debian.org/fetch.php?pkg=kdepimver=4% 3A3.4.2-1arch=m68kstamp=1125779412file=logas=raw Can you please use gcc-3.4 on these arch ? Regards, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321360: Bug actually in linux-kernel-headers
Hi, For the record, this bug is actually due to an error in the linux-kernel-headers. I already filed a bug for it a couple of weeks ago, see #321246. Regards, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#295227: Bug to be closed ?
Hi, It looks like there is no more enigma package in experimental, and a version higher than the one which FTBFS is in the archive (0.92 vs 0.90-rc1), built on every architecture. Maybe this bug could/should be closed ? HTH Regards, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#264063: Bugs should be closed
Hi, Innovation3d has been removed from the archive last month, I suppose these RC bugs should be closed, as well as the following (I only sent this mail to the RC ones to avoid flooding): 270341 205065 225756 Regards, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#211663: Bug should be closed
Hi, the package op-showimg-fb seems to have been removed for some time from the archive, so this big can probably be closed now. Regards, Regis -- While a monkey can be a manager, it takes a human to be an engineer Erik Zapletal
Bug#314639: Bug should be closed
Hi Sam, This bug is against version 3.2-2 of the package with no fastjar build-depends. The has been fixed with the 3.2-3 upload, so this bug should probably be closed. Andreas, could you please check everything builds fine with the latest version ? Regards, Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300573: config.sub and config.guess
Hi, I don't have any of the architectures on which it fails, but I think I found one of the reasons of the FTBFS. The config.sub and config.guess files in the libical-0.23 directory are oudated (1999). The attached patch should at least fix the problem seen on the s390 and parisc buildds. Regards, Regis diff -urN sylpheed-claws-vcalendar-plugin-0.9.or/debian/rules sylpheed-claws-vcalendar-plugin-0.9/debian/rules --- sylpheed-claws-vcalendar-plugin-0.9.or/debian/rules 2005-06-17 18:11:23.245955440 +0100 +++ sylpheed-claws-vcalendar-plugin-0.9/debian/rules2005-06-17 18:22:26.390142200 +0100 @@ -54,9 +54,11 @@ -$(MAKE) distclean ifneq $(wildcard /usr/share/misc/config.sub) cp -f /usr/share/misc/config.sub config.sub + cp -f /usr/share/misc/config.sub $(ICAL)/config.sub endif ifneq $(wildcard /usr/share/misc/config.guess) cp -f /usr/share/misc/config.guess config.guess + cp -f /usr/share/misc/config.guess $(ICAL)/config.guess endif dh_clean
Bug#312525: 312525 explaination
Hi,
The reason it fails is fairly simple. Instead of linking using -lxmms,
this module links against libxmms using dlopen. As it dlopen's
'libxmms.so' which is only provided by xmms-dev... well it doesn't work
if the package is not present.
To fixes are possible. Either making the dlopen against the library
soname, 'libxmms.so.1', which is a quick fix (patch attached) but will
be broken if the soname changes, but I doubt it will for XMMS.
The other solution is to modify to link the usual way, but it would
require a more intrusive patch.
By the way, I miss a bit the point of using dlopen to access libxmms for
an xmms plugin.If someone knows...
I hope this little explaination will be helpful.
Regis
diff -urN xmms-jack-0.14/jack.c xmms-jack-0.14.patch/jack.c
--- xmms-jack-0.14/jack.c 2005-04-16 02:29:55.0 +0100
+++ xmms-jack-0.14.patch/jack.c 2005-06-15 19:53:19.163586432 +0100
@@ -61,7 +61,7 @@
MAKE_FUNCPTR(xmms_convert_buffers_new);
MAKE_FUNCPTR(xmms_convert_buffers_destroy);
MAKE_FUNCPTR(xmms_convert_get_frequency_func);
-void *xmmslibhandle; /* handle to the dlopen'ed libxmms.so */
+void *xmmslibhandle; /* handle to the dlopen'ed libxmms.so.1 */
static int isXmmsFrequencyAvailable = 0;
@@ -205,7 +205,7 @@
/* jack client list */
JACK_SetClientName(xmms-jack);
- xmmslibhandle = dlopen(libxmms.so, RTLD_NOW);
+ xmmslibhandle = dlopen(libxmms.so.1, RTLD_NOW);
if(xmmslibhandle)
{
fp_xmms_convert_buffers_new = dlsym(xmmslibhandle, xmms_convert_buffers_new);
@@ -242,7 +242,7 @@
}
} else
{
-TRACE(unable to dlopen '%s'\n, libxmms.so);
+TRACE(unable to dlopen '%s'\n, libxmms.so.1);
}
/* only initialize this stuff if we have the functions available */
Bug#298674: ftbfs [sparc] cannot find -lccscript
Hi, I have been looking at this bug, and it appears that the actual problem comes from the libccscript package. For some reason, the library crashes and returns a Bus Error. I supose the same happens on ia64 and hppa which FTBFS too. The result is that the test in the configure file returns an empty string instead of the expected 2, and project is then linked using -lccscript where it should be -lccscript2. I have tried to revert to a version of libccscript which seemed to work one the buildds (2.5.6-3, picked from snapshot.), but I keep getting the same error, so it is probably deeper than expected. I'm not sure if this bug should be closed or reassigned, but even if it was built, bayonne looks unusable on some architectures anyway. Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289838: bacula-director-pgsql diff
Hi J.L., In case you are interested, here is the latest patch I made against bacula 1.36.1-1. Unfortunately is send it just after another one has been proposed. It adds support for a remote database by temporarily storring the password in the bacula .pgpass file. I have also updated the templates file to be more explicit about what is nedded and the potential security issues in the way I have had to do things. As it contains some major modifications, you may not want to include what there is in it immediately, if at all. However, by playing around with it, I noticed a couple of details : -if the patch 10-grant_pgsql_privileges.patch is not applied, the bacula user will always have the same password to connect to the database. It might not be a very safe thing. That's why I reenabled it. -It looks like debhelper does not like having a variable named db_password. It doesn't ask the question, and as a consequence the password would be the default one for any installation. Not a very safe thing again. Anyway, feel free to use it, pick ideas in it, or ask me to modify things if you think it's worth it. If you want some help for other points in this package, please feel free to ask. Regards, Regis diff -urN bacula-1.36.1-1/debian/bacula-director-pgsql.config bacula-1.36.1/debian/bacula-director-pgsql.config --- bacula-1.36.1-1/debian/bacula-director-pgsql.config 2005-03-03 11:45:44.824294824 + +++ bacula-1.36.1/debian/bacula-director-pgsql.config 2005-03-03 11:51:30.149797368 + @@ -16,30 +16,20 @@ CATALOG=bacula case $1 in -configure) +configure | reconfigure) - # We leave out config for other hosts, for now + db_fget bacula-director-pgsql/pghost seen || true + if [ $RET = true -a $1 = configure ]; then + exit 0 + fi + + db_beginblock + db_input medium bacula-director-pgsql/pghost || true +# db_input medium bacula-director-pgsql/db_user || true + db_input medium bacula-director-pgsql/pgpassword || true + db_endblock + db_go - #db_input medium bacula-director-pgsql/db_host || true - db_get bacula-director-pgsql/db_host - DB_HOST=$RET - - #if [ $DB_HOST != localhost ]; then - #db_beginblock; - # db_input medium bacula-director-pgsql/db_user || true; - # db_input medium bacula-director-pgsql/db_password || true; - #db_endblock; - #db_go; - #else - ## localhost = just ask for password, so we don't - ## have to invent it - # user 'bacula', we use $HOME/.pgpass - db_input medium bacula-director-pgsql/db_password || true; - db_go; - #fi - - # This MUST be a clean installation -- no packaged version - # had PgSQL support before. db_input medium bacula-director-pgsql/create_tables || true db_go @@ -50,7 +40,8 @@ db_input medium bacula-director-pgsql/pgsql_root_username || true db_go - if [ $DB_HOST != localhost ]; then + db_get bacula-director-pgsql/pghost + if [ $RET != localhost ]; then # if localhost, we need not ask for the password :-) db_input medium bacula-director-pgsql/pgsql_root_password || true db_go @@ -61,83 +52,6 @@ db_go ;; - reconfigure) - - echo -# # We have all dependencies configured, so we can be a bit more clever :) -# # -# db_beginblock -# db_input medium bacula-director-pgsql/host || true -# db_input medium bacula-director-pgsql/user || true -# db_input medium bacula-director-pgsql/password || true -# db_endblock -# db_go - -# db_get bacula-director-pgsql/db_host; MYSQL_HOST=$RET; -# db_get bacula-director-pgsql/db_user; MYSQL_USER=$RET; -# db_get bacula-director-pgsql/db_password; MYSQL_PSWD=$RET; -# if [ $MYSQL_HOST != localhost ]; then -# MYSQL_HOST_STRING=-h $MYSQL_HOST -# fi -# if [ -z $MYSQL_PSWD ]; then -# MYSQL_CMD=mysql $MYSQL_HOST_STRING -u $MYSQL_USER; -# else -# MYSQL_CMD=mysql $MYSQL_HOST_STRING -u $MYSQL_USER -p$MYSQL_PSWD; -# fi - -# # if psql-client is not
Bug#289838: Working on it
Hi, I am not a PostgreSQL specialist, but to become a DD I have been asked to send patches to fix some RC bugs, so... Anyway, I am currently working on these issues, and I have managed to get this package installed correctly, and the database created. It would need a few more tests, but is looks like the modifications to the postinst script might close #272191 as well. This patch also adds support for deleting the database if the DB server is on localhost. If someone could test this patch and give a report on it, it would be nice. J.L., as I am working the scripts for this package, would you like me to continue and try to add support for remote database servers ? Regards, Regis diff -urN bacula-1.36.1/debian/bacula-director-pgsql.postinst bacula-1.36.1_patched/debian/bacula-director-pgsql.postinst --- bacula-1.36.1/debian/bacula-director-pgsql.postinst 2005-02-20 20:52:30.300692272 + +++ bacula-1.36.1_patched/debian/bacula-director-pgsql.postinst 2005-02-20 22:24:45.865158560 + @@ -46,42 +46,47 @@ db_get bacula-director-pgsql/db_host || true PGSQL_HOST=$RET + + db_get bacula-director-pgsql/pgsql_root_username || true + DB_ADMIN=$RET # default: localhost if [ $PGSQL_HOST != localhost ]; then PGSQL_HOST_STRING=-h $PGSQL_HOST export PGUSER=$DB_ADMIN - PGSQLCMD=/usr/bin/psql $PGSQL_HOST_STRING else # 'localhost' install if ! getent passwd $DB_ADMIN /dev/null ; then echo -e \nFATAL: the specified DB Administrator does not exist in 'passwd' databases exit 1 fi - PGSQLCMD=su -s /bin/sh $dbadmin -c /usr/bin/psql + SUPOSTGRES_CMD=su -s /bin/sh $DB_ADMIN -c fi + +PGSQLCMD=/usr/bin/psql $PGSQL_HOST_STRING # Non-local setups are not yet supported. # Patches are welcome !!! echo -n Checking DB connectivity... -if ! $PGSQLCMD -l /dev/null 21; then +if ! $SUPOSTGRES_CMD $PGSQLCMD -l /dev/null 21; then echo -e \nFATAL: Could not connect to PostgreSQL server at $PGSQL_HOST exit 1 fi echo Ok. + CREATE_DB=`$SUPOSTGRES_CMD $PGSQLCMD -l | grep bacula` || true db_get bacula-director-pgsql/create_tables || true - if [ $RET = true ]; then + if [ $RET = true -a -z $CREATE_DB ]; then if [ $PGSQL_HOST = localhost ]; then # localhost, so we can go the easy way :-) # We are already DB_ADMIN -- no need to worry about privileges echo -n Creating Catalog \$CATALOG\ at 'localhost'... - if ! eval $PGSQLCMD -d 'template1' -c \CREATE DATABASE bacula;\; then + if ! $SUPOSTGRES_CMD $PGSQLCMD template1 -c \CREATE DATABASE $CATALOG;\ /dev/null 21; then echo -e \nERROR: Database creation failed!; exit 1; fi @@ -95,7 +100,7 @@ # Create tables echo -n Creating tables ... - if ! su -s /bin/sh $DB_ADMIN -c $MAKE_SQL_TABLES /dev/null 21 + if ! $SUPOSTGRES_CMD $MAKE_SQL_TABLES /dev/null 21 then echo -e \nERROR: Table creation failed! exit 1 @@ -110,7 +115,7 @@ export DBUSER DBPASS echo -n Granting privileges ... - if ! $GRANT_SQL_TABLES /dev/null 21 + if ! $GRANT_SQL_TABLES /dev/null 21 then echo -e \nERROR: Granting privileges failed! exit 1 @@ -161,7 +166,7 @@ DBUSER=bacula export DBUSER DBPASS echo -n Granting privileges ... - if ! $GRANT_SQL_PRIVS /dev/null 21 + if ! $SUPOSTGRES_CMD $GRANT_SQL_PRIVS /dev/null 21 then echo -e \nERROR: Granting privileges failed! exit 1 @@ -170,7 +175,7 @@ #AUTHFILE=`getent passwd bacula | cut -d ':' -f 6`/.pgpass AUTHFILE=/var/lib/bacula/.pgpass - echo localhost:*:bacula:$DB_USER:$DB_PASS $AUTHFILE + echo localhost:*:bacula:$DBUSER:$DBPASS $AUTHFILE chown bacula:root $AUTHFILE # reported by Shin-young Yune chmod 0600 $AUTHFILE @@ -183,7 +188,7 @@ echo -n Processing configuration ... TARGET=$CFGFILE.dpkg-tmp - sed -e s/dbname = bacula;/dbname = bacula; DB Address = $PGHOST;/ \ + sed -e s/dbname = bacula;/dbname = bacula; DB Address = $PGSQL_HOST;/ \ -e s/@db_user@/$DBUSER/ -e s/@db_pswd@/$DBPASS/ \ $DEFCONFIG/bacula-dir.conf $TARGET diff -urN bacula-1.36.1/debian/bacula-director-pgsql.postrm bacula-1.36.1_patched/debian/bacula-director-pgsql.postrm --- bacula-1.36.1/debian/bacula-director-pgsql.postrm 2005-02-20 20:52:30.289693944 + +++ bacula-1.36.1_patched/debian/bacula-director-pgsql.postrm 2005-02-20 22:25:56.397436024 + @@ -22,12 +22,28 @@ CONFFILE=/etc/bacula/bacula-dir.conf +CATALOG=bacula case $1 in purge) rm -f $CONFFILE $CONFFILE.dist # Drop Bacula's user privileges? Can't do - # Potentially, drop DB ... Can't do? + # Potentially, drop DB ... Works only for localhost so far + + db_get bacula-director-pgsql/db_host || true + PGSQL_HOST=$RET + + db_get bacula-director-pgsql/pgsql_root_username || true + DB_ADMIN=$RET + + db_get
