Bug#804326: [Pkg-ace-devel] Bug#804326: Bug#804326: ace: FTBFS: SSLv3 methods removed
Hello, On 11/07/2015 03:49 PM, Kurt Roeckx wrote: On Sat, Nov 07, 2015 at 02:36:38PM +0100, Johnny Willemsen wrote: Hi, Please create a pull request for the necessary changes, ACE is hosted upstream at https://github.com/DOCGroup/ATCD/. https://github.com/DOCGroup/ATCD/pull/156 I think we can make it Debian specific until it gets integrated upstream. Regards, Thomas
Bug#767423: #767423
tag 767423 + moreinfo thanks Hello, the stacktrace you provide shows two messages that could explain the error: (tracker-extract:18870): libmediaart-CRITICAL **: media_art_process_buffer: assertion 'artist != NULL || title != NULL' failed (tracker-extract:18870): Tracker-WARNING **: Could not process media art for 'file:///home/SNIP/test.flac', No error given Is it possible that you share this flac file? Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723856: RE : [Pkg-ace-devel] Bug#723856: rebuild
Yes, that's fine. Thanks for doing it. Original message Subject: [Pkg-ace-devel] Bug#723856: rebuild From: Barak A. Pearlmutter ba...@cs.nuim.ie To: 723...@bugs.debian.org CC: With the binary ace packages in sid, ivtools fails to build. Ivtools has been booted from testing due to this ace problem! If I rebuild ace 6.0.3+dfsg-0.1 using the current tool chain, it compiles just fine. If I install the result, I can build ivtools 1.8.10 and the pending 1.8.11. So if a rebuilt ace were in the archive, ivtools can get back into testing. Since this ace issue is affecting other packages (mine!), I'll upload a binary rebuild NMU (-0.2) with no source changes to a 3-day delay queue. Hope that is okay. Cheers, --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ ___ Pkg-ace-devel mailing list pkg-ace-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ace-devel
Bug#701300: RE : Re: [Pkg-ace-devel] Bug#701300: ld weak symbols or ACE problem?
Original message Subject: Re: [Pkg-ace-devel] Bug#701300: ld weak symbols or ACE problem? From: Agustin Martin agmar...@debian.org To: ?? ?? pashev.i...@gmail.com,701...@bugs.debian.org CC: Debian ACE+TAO maintainers pkg-ace-de...@lists.alioth.debian.org Hello, Sorry I have missed that report. I had a similar, private email report, with the same claim. So it's likely to be needed, even though I don't understandyet why. Thomas
Bug#697848: [Pkg-ace-devel] Bug#697848: NMU of ace ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On 23/01/2013 22:16, Ralf Treinen wrote:
the source package is now available at
http://people.debian.org/~treinen/ace/
I would appreciate if you could check that everything is fine
before I will upload it to sid. If possible I would like to upload
over the coming weekend at latest.
[...]
Finally I played it as conservative as possible and left the tao*
files under debian/ as they do not hurt. Here is the changelog
entry:
ace (6.0.3+dfsg-0.1) unstable; urgency=low
* NMU with maintainers blessing. * Remove upstream files with
nonfree licence (closes: #697848) or without source (closes:
#697847): - repack the orig tarball by removing:
bin/LabVIEW_RT/*.exe examples/{C++NPv2,C++NPv1,APG}/ TAO/ -
debian/control: drop all packages named *tao* - debian/rules: drop
everything related to tao - remove all hunks applying to TAO files
in patch reduce-doxygen-doc.diff - drop patch 34-bts386713.diff
since it applies only to TAO files. - debian/copyright: remove
copyright entries of TAO/, and of the directories under examples/
that have been removed. * Bump version in build-dependency on
debhelper to =9 since we are using debhelper compatibility level
9.
-- Ralf Treinen trei...@debian.org Wed, 23 Jan 2013 21:27:40
+0100
I've reviewed the changes: you did a really good job. A minor issue
remain since some packages now suggest no longer existing tao packages.
(But I have to admit I have no idea why these suggestions were written
in the first place.)
I am doing a compilation now, results expected sooner than tomorrow I
guess now that TAO was stripped off.
Unless something weird happens during that build I approve your
changes.
In what concerns a new tao package for nonfree I leave that to
you ...
However, it certainly is too late in the release process to
introduce a new tao-nonfree package into wheezy/non-free.
Probably. Bad timing, really. I'm sad that the next Debian release will
not include TAO.
Thanks for your work,
Regards,
Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEC8cMACgkQz2LXlDjmjg5WmQCdFF2rtMqNJMgFckSa79ovaOdi
iL4An05AfpbLIdiTDJkMx+4Pnqwed0ey
=a04o
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697848: [Pkg-ace-devel] Bug#697848: Bug#697848: NMU of ace ?
Hello, On 22/01/2013 23:30, Pau Garcia i Quiles wrote: I'm afraid Johnny was not CC'ed in your mail, do not forget to add pkg-ace-devel to the CC list There's no need to add pkg-ace-devel@ since bug #697848 is on ace, the maintainer (pkg-ace-devel@) gets all mail about it. Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697848: NMU of ace ?
Hello, On 23/01/2013 08:33, Ralf Treinen wrote: Relicensing is probably the best solution, generally speaking, but I suppose it will come too late for wheezy. Ack. On 23/01/2013 09:08, Johnny Willemsen wrote: Agreed, but I believe Sun intent here was to ensure that standardization and implementation efforts (IDL to C++ and IIOP marshalling rules) do not get ruined by code modifications. Yes, I am interpreting. @Johnny: any opinion on this? See [1] for the context. The intent of Sun is to keep IIOP mandatory in the code, but as far as I know we can ship the code without problems. Ok, so assuming eventually ridlc replaces TAO_IDL, we'll still have the IIOP issue. Any chance to have this piece of code relicensed? How can we proceed? Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697848: [Pkg-ace-devel] Bug#697848: NMU of ace ?
Hello, On 23/01/2013 08:39, Ralf Treinen wrote: OK. Here is what I will try tonight when I get back from work: - repack the orig.tar.gz without the two windows executables, the TAO source tree, and the files in examples/ that are under Addison Wesley licence. There is something slightly easier here: pick the ACE only tarball [1] that does not suffer from all issues mentioned before except for the bin/LabVIEW_RT Windows executables. - remove all tao-related packages from debian/control, that is Package: libtao-2.1.2 Package: libtao-dev Package: libtao-doc Package: libtao-orbsvcs-2.1.2 Package: libtao-orbsvcs-dev Package: libtao-qtresource-2.1.2 Package: libtao-qtresource-dev Package: libtao-xtresource-2.1.2 Package: libtao-xtresource-dev Package: libtao-flresource-2.1.2 Package: libtao-flresource-dev Package: libtao-tkresource-2.1.2 Package: libtao-tkresource-dev Package: libtao-foxresource-2.1.2 Package: libtao-foxresource-dev Package: tao-idl Package: tao-ifr Package: tao-imr Package: tao-ft Package: tao-utils Package: tao-cosnaming Package: tao-naming Package: tao-costrading Package: tao-trading Package: tao-cosevent Package: tao-event Package: tao-rtevent Package: tao-ftrtevent Package: tao-cosnotification Package: tao-notify Package: tao-load Package: tao-tls Package: tao-log Package: tao-scheduling Package: tao-cosconcurrency Package: tao-concurrency Package: tao-coslifecycle Package: tao-lifecycle Package: tao-costime Package: tao-time - remove all files from debian/ that are related to these packages, and other mentions of tao stuff in debian/rules and possibly elsewhere in debian/* files. In what concerns a new tao package for nonfree I leave that to you ... This plan looks good, thanks for stepping in; this is really appreciated. I might be able to help if needed from Friday on. Thanks, Regards, Thomas [1] http://download.dre.vanderbilt.edu/previous_versions/ACE-src-6.0.3.tar.bz2 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697847: Bug#697848: NMU of ace ?
Hello, On 22/01/2013 13:55, Pau Garcia i Quiles wrote: On Tue, Jan 22, 2013 at 9:10 AM, Ralf Treinen trei...@free.fr mailto:trei...@free.fr wrote: I may help with uploading an ace with a repackaged source if necessary. Thanks for offering your help. I have requested a refresh on my updated GPG key but so far I got no news. In your opinion, which files would have to be dropped ? How would dropping parts of the source affect the packaging ? Most of the files affected by these two bug reports have been acknowledged by upstream and a solution is already been approved but not yet implemented. Regarding #697847, the files under bin/LabVIEW_RT can be removed. I'm more annoyed by #697848. The first two issues raised by Ansgar were not yet discussed with upstream because I need a confirmation on what is exactly the issue. If this is what I underlined in my reply then I am afraid we will have no easy solution except for moving ace to non-free. Thomas: I can also upload The DM procedure has changed [1] and I'm afraid I will not be able to give you the rights until my key gets refreshed. Thanks, Regards, Thomas [1] https://lists.debian.org/debian-devel-announce/2012/09/msg8.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697848: NMU of ace ?
On 22/01/2013 21:40, Ralf Treinen wrote: I'm more annoyed by #697848. The first two issues raised by Ansgar were not yet discussed with upstream because I need a confirmation on what is exactly the issue. If this is what I underlined in my reply then I am afraid we will have no easy solution except for moving ace to non-free. I am afraid I agree with Ansgar that the licence is rife with problems, in particular the part where you are not allowed to remove functionality. This can be read as forbidding to rip part of the source code and reuse it in a different projet. Can it be DFSG-free if this is not allowed ? Agreed, but I believe Sun intent here was to ensure that standardization and implementation efforts (IDL to C++ and IIOP marshalling rules) do not get ruined by code modifications. Yes, I am interpreting. @Johnny: any opinion on this? See [1] for the context. Different parts of the source code are covered by different licences. The question for me was rather whether it is possible to keep a kernel ace package containing only source code that is not covered by problematic licences, and possibly move the rest into an ace-nonfree package. Are you saying that this is not possible, and that the only possible action would be to move everything to non-free? I don't know anything about the structure of the ace package. ace source package consists in the following software: - ACE, a C++ networking library - TAO, a CORBA ORB built on top of ACE What is faulty here is TAO_IDL (idl to C++ mapping) and a piece of marshalling code (again, for TAO). So ACE can remain in main, but TAO has to go to non-free. This means two repackaging: one for ACE and another for TAO (not distributed stand-alone ATM) in non-free. Thanks, Regards, Thomas [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697848#10 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697848: [Pkg-ace-devel] Bug#697848: non-free files in main
Hello, thanks for the report. On 10/01/2013 12:30, Ansgar Burchardt wrote: Package: src:ace Severity: serious [...] the following license conditions (from 6.1.2-1's d/copyright) look quite non-free as they restrict how the program may be modified: I assume you are referring to DFSG#3 here? Or DFSG#1? [...] You may copy and extend functionality (but may not remove functionality) of the Interface Definition Language CFE without charge, but you are not authorized to license or distribute it to anyone else except as part of a product or program developed by you or with the express written consent of Sun Microsystems, Inc. (Sun). My reading of the text above is that it's possible to license or distribute IDL CFE to anyone if: - the licensee has express written consent of Sun Microsystems, Inc. (Sun); or - it's part of a product or program developed by the licensee While first condition is impossible to meet, the second one looks similar (to me) to DFSG#1. But maybe the issue here is the /but may not remove functionality/ sentence? You may copy, modify, distribute, or sublicense the LICENSED PRODUCT without charge as part of a product or software program developed by you, so long as you preserve the functionality of interoperating with the Object Management Group's Internet Inter-ORB Protocol version one. However, any uses other than the foregoing uses shall require the express written consent of Sun Microsystems, Inc. Likewise, I don't see what's wrong here, except maybe for /so long as you preserve the functionality of interoperating with the Object Management Group's Internet Inter-ORB Protocol/ Is this the part that triggered this bug report? There's also a license allowing only educational and commercial use, but no redistribution or modification: All of the files in these directories are copyright Addison Wesley, and they come with absolutely no warranty whatsoever. Permission is hereby granted to use these programs for educational or commercial purposes. Ack. Repackaging would solve this one. Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697847: [Pkg-ace-devel] Bug#697847: missing source for Win32 binaries
tags 697847 + confirmed thanks On 10/01/2013 12:26, Ansgar Burchardt wrote: The source for bin/LabVIEW_RT/*.exe seems to be missing from the source package (at least from 6.0.3-5 and 6.1.2-1). As they seem to be related to LabVIEW I suspect they cannot be built in Debian either. Hello, thanks for the report. The .exe is not used for building nor is it distributed. We need a repackaged version for this. Since my GPG key has expired, I will not be able to upload this in a timely fashion, so you can consider this email as a call for NMU. Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665054: dwarves-dfsg: FTBFS: make[3]: *** No rule to make target `/usr/lib/libdw.so', needed by `codiff'. Stop.
tags 665054 + confirmed thanks On 22/03/2012 13:24, Lucas Nussbaum wrote: Relevant part: make[3]: Entering directory `/«PKGBUILDDIR»/debian/build' /usr/bin/cmake -E cmake_progress_report /«PKGBUILDDIR»/debian/build/CMakeFiles 1 [ 50%] Building C object CMakeFiles/codiff.dir/codiff.o /usr/bin/gcc -D_GNU_SOURCE -DDWARVES_VERSION=\v1.9\ -Wall -g -O2 -I/«PKGBUILDDIR»/debian/build -I/«PKGBUILDDIR»-o CMakeFiles/codiff.dir/codiff.o -c /«PKGBUILDDIR»/codiff.c /«PKGBUILDDIR»/codiff.c: In function 'main': /«PKGBUILDDIR»/codiff.c:740:8: warning: variable 'filenames' set but not used [-Wunused-but-set-variable] make[3]: *** No rule to make target `/usr/lib/libdw.so', needed by `codiff'. Stop. make[3]: Leaving directory `/«PKGBUILDDIR»/debian/build' make[2]: *** [CMakeFiles/codiff.dir/all] Error 2 dwarves compilation needs to be tweaked for multiarch. Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656040: [Pkg-ace-devel] Bug#656040: root source of problem found
Hello,
Thanks for your report, and sorry for the late reply.
On 18/01/2012 04:14, Ken Gregson wrote:
I believe I discovered the root cause after downloading and building ACE
and TAO libraries from the upstream sources, an experience that has
caused me to appreciate Even More the work of Debian ACE+TAO
maintainers. In the process, I discovered another minor issue identified
at the bottom of this update.
First, forgot to mention in the initial report (should that matter)
Debian version: Wheezy(testing)
Debian arch: amd64
The problem is actually with package libnetsvcs-6.0.1 rather than
ace-netsvcs as initially reported.
This package should install a symlink to the library installed in
/usr/lib from libnetsvcs.so to libnetsvcs-6.0.1.so.
You'll get that symlink if you install libnetsvcs-dev package, see:
http://packages.debian.org/wheezy/amd64/libnetsvcs-dev/filelist
Or have the server.conf look like:
dynamic Logger Service_Object * ACE:_make_ACE_Logging_Strategy() -s
foobar -f STDERR|OSTREAM|VERBOSE
dynamic Server_Logging_Service Service_Object *
libnetsvcs-6.0.1.so:_make_ACE_Server_Logging_Acceptor() active -p 20009
I see different options here:
1 document this in a README as you suggest
2 change ace_netsvcs so that it somehow replaces netsvcs string with
libnetsvcs-6.0.1.so before proceeding to the loading
3 change ACE shared library loading to teach it how to load its own
libraries using SONAME rather than short name
4 make ace-netsvcs package recommend (or even depend) on libnetsvc-dev
Any opinion on this?
[...]
The other minor additional configuration issue I discovered is that
package libkokyu-dev doesn't depend on libkokyu-6.0.1 (although all the
other {ACE|TAO} -dev packages do depend on their underlying base library).
libkokyu-dev 6.0.1-1 does depend on libkokyu-6.0.1 according to:
http://packages.debian.org/wheezy/libkokyu-dev
Thanks,
Regards,
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644826: ace: Ace FTBFS on armel with ICE
tags 644826 + pending unblock 644826 by 644722 thanks Building now with a patch similar to the one proposed here. Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644826: ace: Ace FTBFS on armel with ICE
forwarded 644722 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48660 tags 644722 + confirmed upstream tags 644826 + confirmed block 644826 by 644722 thanks The issue was reported to upstream by Ubuntu maintainers (thanks to them). Also trackable here: https://bugs.launchpad.net/ubuntu/+source/ace/+bug/736661 The only way to work around this is to use gcc-4.4 on armel. Is this an acceptable work-around, i.e. how long will gcc 4.4 be in unstable? Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630897: [Pkg-ace-devel] Bug#630897: ace: DDS4 spec doesn't allow modification or commercial distribution
fixed 630897 ace/6.0.1-1 thanks Le 21/11/2011 04:21, peter green a écrit : Currently this bug is marked as fixed in stable but unfixed in testing and unstable. There is a comment in the bug report log saying This file has already been removed from the latest ace versions. and the file does not appear to be present in the testing version of the package. However later in the bug report log there is talk of a second undistributable file that is not mentioned by name. Can you confirm the status of this bug in the testing and unstable versions of the package and if it is indeed fixed in the testing and/or unstable mark the bug appropriately. The .pdf is no longer in 6.0.1 tarballs; hence it's fixed in stable, testing and unstable. Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630897: [Pkg-ace-devel] Bug#630897: ace: source includes non DFSG-free DDS spec
Hello,
Le 02/07/2011 18:40, Thomas Girard a écrit :
Should I upload a new ace-dfsg_5.7.7.orig.tar.gz without the pdf file
to s-p-u, and request for its inclusion in the next stable update?
Yes, please rebuild the .orig tarball to remove the file, note that fact
in debian/{copyright,README.source} and upload new packages targeted at
stable.
Note that your suggested tarball name has the repacked source
indicator in the wrong position. The packages should be versioned as
5.7.7+dfsg or similar, so the tarball would be ace_5.7.7
+dfsg.orig.tar.gz.
I've prepared an upload for stable; it can be seen here:
http://thomas.g.girard.free.fr/ACE/stable/
the repackaged tarball being available at:
http://thomas.g.girard.free.fr/ACE/stable/ace_5.7.7+dfsg.orig.tar.gz
Eventually another pdf was also removed, having the same non
distributable statement.
Package patch is attached to this email.
I'm waiting for your approval before proceeding to the upload.
Thanks,
Regards,
Thomas
diff --git a/debian/README.source b/debian/README.source
index 99bcdaf..1d5ff1c 100644
--- a/debian/README.source
+++ b/debian/README.source
@@ -1,3 +1,14 @@
+= Repackaging for 5.7.7+dfsg =
+
+ * The 5.7.7 upstream tarball contains two files:
+
+ $CIAO_ROOT/connectors/dds4ccm/docs/ptc_09-10-26 DDS4CCM v1-0 WCB.pdf
+ $CIAO_ROOT/connectors/dds4ccm/docs/09-10-25.pdf
+
+ that are not distributable and hence were removed from the repackaged
+ tarball.
+
+
= Compiling ACE+TAO Debian packages =
* ACE+TAO+CIAO-src-version.tar.bz2 is retrieved from:
diff --git a/debian/changelog b/debian/changelog
index c9c0714..4220f73 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ace (5.7.7+dfsg-1) stable; urgency=low
+
+ * Repackage to remove non-distributable .pdf files. Closes: #630897.
+
+ -- Thomas Girard thomas.g.gir...@free.fr Sun, 17 Jul 2011 19:09:19 +0200
+
ace (5.7.7-4) unstable; urgency=low
[ Marek Brudka ]
* Synchronized *.pc with *.so and created transitional tags. Closes: #598169
diff --git a/debian/copyright b/debian/copyright
index 3899e12..e75dc2f 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -8,7 +8,8 @@ Then maintained by:
It is now maintained by:
Debian ACE+TAO maintainers pkg-ace-de...@lists.alioth.debian.org
-It was downloaded from: http://download.dre.vanderbilt.edu/
+It was downloaded from: http://download.dre.vanderbilt.edu/, and
+repackaged to remove non-distributable files.
Files: *
Copyright: © 1993-2008 Douglas C. Schmidt and his research group at
Bug#630897: ace: source includes non DFSG-free DDS spec
Hello,
Le 02/07/2011 17:35, Adam D. Barratt a écrit :
It's not just non DFSG-free - it's completely non-distributable. From
the quote in #630897:
(2) the use of the specifications is for informational purposes and
will not be copied or posted on any network computer or broadcast in any
media
Indeed.
ace packages 5.7.7-4 are distributed in Debian stable. The non-free
.pdf is not distributed in the binary packages, and later releases of
the source tarballs no longer include the non-free file (the .pdf is not
included in source packages of Debian unstable).
Should I upload a new ace-dfsg_5.7.7.orig.tar.gz without the pdf file
to s-p-u, and request for its inclusion in the next stable update?
Yes, please rebuild the .orig tarball to remove the file, note that fact
in debian/{copyright,README.source} and upload new packages targeted at
stable.
Note that your suggested tarball name has the repacked source
indicator in the wrong position. The packages should be versioned as
5.7.7+dfsg or similar, so the tarball would be ace_5.7.7
+dfsg.orig.tar.gz.
Ok, will do that.
Does this also affect the ace packages in oldstable?
Fortunately no.
Thanks,
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629657: ace: FTBFS: libACE.so: undefined reference to `clock_gettime'
Hello, Le 13/06/2011 19:39, Hector Oron a écrit : Could you please push the patch to Vcs? I am trying to see what's going on armel build, which produces an ICE on the compiler. I am preparing an upload of ACE+TAO 6.0.3+2.0.3 to experimental. I completely forgot to mention that upload of 5.7.7-3 included a patch (that was integrated upstream afterward) to work around another ICE with armel regarding -fvisibility=hidden. Would you prefer that we revert that patch before the next upload? Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629657: ace: FTBFS: libACE.so: undefined reference to `clock_gettime'
Le 26/06/2011 14:33, Hector Oron a écrit : I am preparing an upload of ACE+TAO 6.0.3+2.0.3 to experimental. I completely forgot to mention that upload of 5.7.7-3 included a patch (that was integrated upstream afterward) to work around another ICE with armel regarding -fvisibility=hidden. Would you prefer that we revert that patch before the next upload? Which patch is it? debian/platform_macros.GNU contains the following snippet: # Work-around #593225 ARMEL_TARGET := $(shell echo '__ARMEL__' | $(CC) -E - | tail -n 1) ifeq ($(ARMEL_TARGET),1) no_hidden_visibility = 1 endif Maybe it could be tested at abel.debian.org before uploading and check whether the patch is needed or not. I think you already have ace build-dep installed in abel. I'll try this. Possibly also decrease optimization level (currently -O3). Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630897: ace: DDS4 spec doesn't allow modification or commercial distribution
tags 630897 + confirmed fixed-upstream thanks Hello, Le 18/06/2011 21:04, Johnny Willemsen a écrit : This file has already been removed from the latest ace versions. Good to know. But since Debian stable version 5.7.7-4 includes it, I think we'll need a stable update for this. Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630897: ace: source includes non DFSG-free DDS spec
Hello, ace_5.7.7.orig.tar.gz includes a non DFSG-free specification .pdf file: ptc_09-10-26 DDS4CCM v1-0 WCB.pdf Sam reported bug #63097[1] about this issue, thanks to him for pointing this out. ace packages 5.7.7-4 are distributed in Debian stable. The non-free .pdf is not distributed in the binary packages, and later releases of the source tarballs no longer include the non-free file (the .pdf is not included in source packages of Debian unstable). Should I upload a new ace-dfsg_5.7.7.orig.tar.gz without the pdf file to s-p-u, and request for its inclusion in the next stable update? Thanks, Regards, Thomas [1] http://bugs.debian.org/630897 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629657: [Pkg-ace-devel] Bug#629657: Bug#629657: ace: FTBFS: libACE.so: undefined reference to `clock_gettime'
Hello, Le 11/06/2011 15:01, Thomas Girard a écrit : I'm testing a fix for this bug. The patch is working fine. I'm having a look at another, unrelated, IPv6 possible bug before uploading a new release. Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622074: [devo-group] ace: FTBFS: SSL_Context.cpp:244:16: error: '::SSLv2_client_method' has not been declared
Hello, Le 11/05/2011 18:20, Steve Huston a écrit : Thomas, is this issue in Bugzilla? If not, please enter it there. It is: http://bugzilla.dre.vanderbilt.edu/show_bug.cgi?id=3958 I don't have an immediate reaction to the choices, but off-the cuff I tend to favor b under configuration control, defaulting to historic behavior allowing sslv2. SSLv2 was removed from Debian openssl version. No way to get it back. Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622074: ace: FTBFS: SSL_Context.cpp:244:16: error: '::SSLv2_client_method' has not been declared
forwarded 622074 http://bugzilla.dre.vanderbilt.edu/show_bug.cgi?id=3958 tags 622074 + upstream thanks Hello, because SSLv2 is considered dangerous, it was disabled from Debian openssl packages[1]. This causes ace 6.0.1 packages to fail to build from source (FTBFS)[2]. We are requesting you opinion/help on how to fix this properly. Quoting [3], we saw 3 different options: a) Keep the SSLv2 entries in the enumerations but make them actually use SSLv3. It has the advantage if the application uses Debian on both sides, there is no need for changes in the application. On the other hand, it may lead to very weird to debug situations if you are connecting to an SSLv2-only service that is not using Debian on the other side (hey, I'm telling it to use SSLv2 yet it fails, yeah, it's because ACE SSLv2 is actually ACE SSLv3). b) Completely remove SSLv2 Meaning: including removal from the enumerations, but keeping the blanks for the former SSLv2 values (to avoid renumerating the enumerations). Advantage: it makes explicit SSLv2 is no longer supported. Disadvantage: I need to check what happens with SSLv23 calls, I can't remember if the code is easy transformable to SSLv3 calls. I think this is the best choice. c) Just disable SSLv2 Meaning: keep the enumerations, keep the methods, but instead of making the calls to OpenSSL, fail. IMHO we should completely discard this. So far we implemented b). But the following use case seems to break it: say we have an application which uses ACE SSLv2: - application recompilation will fail; allowing to switch to SSLv3. - but if it's not recompiled, then the application will silently switch to SSLv3 (because of the default clause in the ACE_SSL_Context::set_mode()) I don't understand this default: clause. I believe ACE_SSL_Context::set_mode() should reject unsupported modes. What do you think? Is the change b), and its side-effect in the scenario above, an acceptable change? Any other idea? Thanks, Regards, Thomas [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589706 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622074 [3] http://lists.alioth.debian.org/pipermail/pkg-ace-devel/2011-April/002458.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624893: bouml: FTBFS: qvaluelist.h:91:13: error: 'ptrdiff_t' does not name a type
reassign 624893 qt-x11-free forcemerge 624893 611255 thanks Hello, this is caused by #611255. Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624740: [Pkg-corba-devel] Bug#624740: python-omniorb: FTBFS without python2.5
Hello, Le 01/05/2011 14:54, Floris Bruynooghe a écrit : On 1 May 2011 06:37, Scott Kitterman deb...@kitterman.com wrote: Package: python-omniorb Version: 3.5-1 Severity: serious Justification: fails to build from source This has been fixed in r267 of svn.debian.org/svn/pkg-corba/trunk/python-omniorb, so someone needs to upload this now. Usually Thomas Girard does this but I don't know how much time he has (we don't tend to be the fastest team ;-)) so if this is urgent for the transition then maybe someone else could upload this after checking with him? I'll upload the fix today. Thanks for your work, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616576: empty binary package
Package: libsigsegv2 Version: 2.9-1 Severity: grave Hello, the 2.9-1 package release does not contain any library on i386: me@machine:~$ dpkg -L libsigsegv2 /. /usr /usr/share /usr/share/doc /usr/share/doc/libsigsegv2 /usr/share/doc/libsigsegv2/changelog.Debian.gz /usr/share/doc/libsigsegv2/copyright /usr/share/doc/libsigsegv2/ChangeLog.1.gz /usr/share/doc/libsigsegv2/NEWS.gz /usr/share/doc/libsigsegv2/changelog.gz /usr/share/doc/libsigsegv2/README.gz /usr/share/doc/libsigsegv2/README.woe32 me@machine:~$ Thanks, Thomas -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.37-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#593225: [Pkg-ace-devel] Bug#593225: Bug#593225: ace: FTBFS on armel: collect2: ld returned 1 exit status
Hello, Le 16/08/2010 15:50, Mehdi Dogguy a écrit : On 08/16/2010 03:44 PM, Johnny Willemsen wrote: Hi, Looks a problem with visibility. What is the exact GCC version used? That's indeed a visibility issue, since deactivating it makes the build process complete. I'll commit a patch for this by the end of the week. Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591586: [Pkg-ace-devel] Bug#591586: config file
Le 04/08/2010 11:26, Johnny Willemsen a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Looks like the wrong config file is included. Yes, that's Linux config file. Since Debian GNU/kFreeBSD[0] is not yet supported upstream, we'll have to provide a working file ourselves (and then submit it upstream). As Marek pointed out, that was one of nice things with the autotools method. But we can surely use 5.6 generated config file[1,2] for ace on GNU/kFreeBSD as a starting point to provide one for 5.7. I won't be able to work on this before at least a week. Any taker? Regards, Thomas [0] http://www.debian.org/ports/kfreebsd-gnu/ [1] http://packages.debian.org/squeeze/kfreebsd-amd64/libace-dev/download [2] http://packages.debian.org/squeeze/kfreebsd-i386/libace-dev/download -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533809: Tagging multiple bugs
tags 533809 + pending tags 550629 + pending tags 552899 + pending thanks Hello, those bugs are fixed in the SVN repo. I'm waiting for my gpg key update to be propagated on the keyring so that I can upload them. Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552899: ace: #552899 dirent issue affecting diagnostics compilation
Package: ace Version: 5.6.3-5 Severity: normal Tags: pending Hello, I have found out what was causing #552899, and I'm currencly testing a fix for this. Regards, Thomas -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25micmac (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518735: [Pkg-ace-devel] Bug#518735: ace: FTBFS: autotools error
Luk Claes wrote: Hi Any further progress in getting this FTBFS fixed? I'm tempted to remove ace from testing if this bug does not get fixed soon. The only reverse dependency which prevents the removal will soon be diagnostics (maintainer Cc-ed). Please don't. I am currently busy but I will have a look at ace RC bugs this week-end. Please prove me wrong in wanting this package removed from testing and get the package fixed and maintained properly again, TIA. Will do. Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518735: [Pkg-ace-devel] Bug#518735: Bug#518735: upgrade ACE/TAO
Pau Garcia i Quiles wrote: On Mon, Oct 26, 2009 at 8:16 AM, Johnny Willemsen jwillem...@remedy.nl wrote: Hi, Is there anyone at debian who has experience with opensuse build service? If someone can take x.7.4 and see what has to be done to the ACE_wrappers/debianbuild package in the distribution, we can integrate it. We really would like to see ACE support debian package support out of the box. I have taken 5.7.4 and working on debianizing it, using 'debianbuild' as a starting point. It does not build yet but I have a few fixes already. Give me a couple of days. I have no experience with the opensuse buildservice but I will provide binary packages for Ubuntu using my PPA: http://launchpad.net/~pgquiles/+archive/ppa Hello Pau, Thanks a lot for working on this. I don't have a lot of spare time these days; sorry for not replying earlier to your first email. I'll have a look at your work ASAP and will sponsor it for Debian. Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489386: diagnostics 0.2.2 FTBFS with g++-4.3 on s390
Package: diagnostics Version: 0.2.2 Severity: serious Justification: no longer builds from source a binary NMU rebuild of diagnostics shows diagnostics FTBFS on s390[1]. A NMU will follow, as requested by the maintainer. Regards, Thomas [1] http://buildd.debian.org/fetch.cgi?pkg=diagnostics;ver=0.2.2%2Bb1;arch=s390;stamp=1214648343 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25micmac (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489386: diagnostics 0.2.2 FTBFS with g++-4.3 on s390
Please find attached the patch used for the NMU (without the autotools part). Regards, Thomas diff -Nru diagnostics-0.2.2/debian/changelog diagnostics-0.2.2+nmu1/debian/changelog --- diagnostics-0.2.2/debian/changelog 2008-01-23 23:04:38.0 +0100 +++ diagnostics-0.2.2+nmu1/debian/changelog 2008-07-05 13:58:09.0 +0200 @@ -1,3 +1,11 @@ +diagnostics (0.2.2+nmu1) unstable; urgency=low + + * Non-maintainer upload, as requested by Michael. + * Work-around a g++ 4.3 bug on s390 causing the package to FTBFS on this +arch (closes: #489386) + + -- Thomas Girard [EMAIL PROTECTED] Sat, 05 Jul 2008 13:51:35 +0200 + diagnostics (0.2.2) unstable; urgency=low * stream_test_system.cpp: #include cstring to fix FTBFS with gcc 4.3 diff -Nru diagnostics-0.2.2/diagnostics/macros/invariance_annotation.t.cpp diagnostics-0.2.2+nmu1/diagnostics/macros/invariance_annotation.t.cpp --- diagnostics-0.2.2/diagnostics/macros/invariance_annotation.t.cpp 2007-03-01 22:43:26.0 +0100 +++ diagnostics-0.2.2+nmu1/diagnostics/macros/invariance_annotation.t.cpp 2008-07-05 13:59:31.0 +0200 @@ -157,7 +157,7 @@ private: mutable int m_class_invariance_called; -bool m_throw; +volatile bool m_throw; };
Bug#432541: Closing bug properly
found 432541 tags 432541 - confirmed help close 432541 thanks That bug got fixed with the gcc-4.3/4.3.0-2 upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481668: frysk: can't be run with libgtk-java ( 2.10.2-6)
tag 481668 + confirmed thanks Hello Jiří, Le samedi 17 mai 2008 à 21:45 +0200, Jiří Paleček a écrit : Hello, I was just about to test and close #470803, but I've found out I couldn't even run frysk. The error message is: [EMAIL PROTECTED]:/usr/src/dfsbuild$ frysk libgcj failure: gcj linkage error. Incorrect library ABI version detected. Aborting. Aborted The reason is frysk depends on libgcj7, while everything else (meaning libraries frysk depends on) depends on libgcj9. For a discussion on a similar problem, see http://groups.google.com/group/linux.debian.devel/msg/325b87794a15f9f8 Yes, I can see this as well. This bug will be fixed when frysk 0.3 is uploaded. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477312: FTBFS (ia64/experimental): Test suite failure (120)
forwarded 477312 http://smalltalk.gnu.org/project/issue/213 thanks Hello, I've just tried backporting the Swazoo race patch (that is git commit dfd82e2fef20429c40f0deaedc2154e9c10f5802) but test 120 still fails. The bug report continues on http://smalltalk.gnu.org/project/issue/213 Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477850: cairo-java: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
Hello Matthias, Le vendredi 25 avril 2008 à 18:36 +0200, Matthias Klose a écrit : gij/gcj and java-gcj-compat are not available (anymore) on the following architectures: alpha, arm, hppa and hurd-i386. This package has been identified as a package which build-depends on gcj or java-gcj-compat-dev and builds at least one architecture dependent package, and is unbuildable in unstable. If this report is a false positive, please close it. All gcj related build dependencies have to restricted to these architectures on which a java or java compatible development kit / compiler is available, i.e. java-gcj-compat [!alpha !arm !hppa !hurd-i386] As a second step please consider changing the java-gcj-compat-dev b-d to default-jdk-builddep, making the package independent of a specific implementation and depend on the jdk, which is most suitable for this architecture. default-jdk-builddep will depend in addition on java-gcj-compat-dev, even if the default jdk is another one (to allow to compile byte-code to native code using dh_nativejava). I am not sure I see what the proper fix is for this bug: * changing the build-dependencies from: gcj, java-gcj-compat-dev to: gcj [!alpha !arm !hppa !hurd-i386], java-gcj-compat-dev [!alpha !arm !hppa !hurd-i386] will prevent installing a non-existent build-dep on these arches at compile time. * source packages that produce -gcj, -jni (or even -cni) binary packages - that is arch-dep packages - should no longer be autobuilt on the alpha, arm, hppa, hurd-i386 arches. But how? Is it enough to change all Architecture: any packages to Architecture: i38 amd64 ..., i.e. everything but the unsupported arches? (Unfortunately we can't use the negated notation here AFAIK.) * the Architecture: all packages usually depend on: java-gcj-compat | java2-runtime so this again should be changed to: java-gcj-compat [!alpha !arm !hppa !hurd-i386] | java2-runtime * changing java-gcj-compat to default-jdk and java-gcj-compat-dev to default-jdk-dev does not change anything with respect to the arches issue: for now there's no such packages on the gcj-unsupported arches. Will this change? If the answer is no, this means the same notations have to be used with the new package. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477312: FTBFS (ia64/experimental): Test suite failure (120)
Hello, Le mardi 22 avril 2008 à 13:15 +0200, Paolo Bonzini a écrit : It might be that rebuilding fixes the failure. I saw random failures of Swazoo here too, it might be a race condition or something like that. Paolo, could this error be fixed by the patch[1]? Regards, Thomas [1] http://git.sv.gnu.org/gitweb/?p=smalltalk.git;a=commitdiff;h=dfd82e2fef20429c40f0deaedc2154e9c10f5802
Bug#476822: ace - FTBFS: error: ACE_FoxReactor cannot be enabled: fox-config not found.
tags 476822 + confirmed pending thanks On Sat, Apr 19, 2008 at 02:03:07PM +0200, Bastian Blank wrote: Package: ace Version: 5.6.3-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of ace_5.6.3-1 on debian-31.osdl.marist.edu by sbuild/s390 98 [...] checking whether tclConfig.sh exists in /usr/lib/tcl8.4... yes checking whether tkConfig.sh exists in /usr/lib/tk8.4... yes checking for fox-config... no checking for Kerberos include flags needed by OpenSSL... no checking for OpenSSL libraries... yes configure: error: ACE_FoxReactor cannot be enabled: fox-config not found. Hello Bastian, thanks for the report. I had already noticed this, the bug is fixed in SVN. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476505: ace_5.6.3-1(sparc/unstable): FTBFS: QT not found while configuring
Hello, On Thu, Apr 17, 2008 at 10:52:15AM +0200, Sune Vuorela wrote: Hi! Please try give back the build with a dep-wait on libqt4-dev (=4.4~rc1-4) - it has most likely fixed this issue. Thanks for the notice. Anyway, there's another missing build-dependency on Fox, so ace will definitely need another upload. Thanks, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476295: java-gnome: pango_context_new, pango_font_map_get_shape_engine_type implicitly converted to pointers
forwarded 476295 http://bugzilla.gnome.org/show_bug.cgi?id=528282 thanks Hello, this bug was forwarded upstream. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476295: java-gnome: pango_context_new, pango_font_map_get_shape_engine_type implicitly converted to pointers
Hello dann, On Tue, Apr 15, 2008 at 11:00:30AM -0600, dann frazier wrote: Our automated buildd log filter[1] detected a problem that is likely to cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. Function `pango_context_new' implicitly converted to pointer at generated/bindings/org/gnome/pango/PangoContext.c:34 Function `pango_font_map_get_shape_engine_type' implicitly converted to pointer at generated/bindings/org/gnome/pango/PangoFontMap.c:120 This is often due to a missing function prototype definition. For more information, see [2]. The prototypes for both pango_context_new and pango_font_map_get_shape_engine_type are both wrapped in an #ifdef PANGO_ENABLE_BACKEND in their respective header files. Perhaps defining this at compile time would solve this? Though it is guaranteed that this codepath will cause a segfault on certain architectures, it is not guaranteed that this codepath would ever be executed (e.g., if the returned pointer is never dereferenced). However, this bug does prevent the ia64 buildd from successfully building this package, resulting in a practical FTBFS issue and warranting the serious severity. [1] http://people.debian.org/~dannf/check-implicit-pointer-functions [2] http://wiki.debian.org/ImplicitPointerConversions Thanks a lot for the report and the explanation. That's a very useful build feature! I'm working on a fix. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473953: gnu-smalltalk: FTBFS: tests failed
tags 473953 + unreproducible thanks Hello, I have not been able to reproduce this failure. Even with a read-only or non-existent home. On Wed, Apr 02, 2008 at 12:46:33PM +0200, Lucas Nussbaum wrote: The full build log is available from: http://people.debian.org/~lucas/logs/2008/04/01 From that log, I see strange lines with No data available, e.g. when building the Smalltalk image used for tests that fail: ls: /build/user/gnu-smalltalk-3.0.2/gst: No data available Any idea what might be causing this? Thanks, Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472020: [Pkg-corba-devel] Bug#472020: python-omniorb: ftbfs with fixed python-central
tags 472020 + pending thanks Hello, On Fri, Mar 21, 2008 at 07:22:07PM +0100, Matthias Klose wrote: python-central 0.6 fixes bug #452227, removing an empty directory usr/lib. Your package tries to remove that directory as well, not ignoring the error code. Please either ignore the error code, or remove the directory removal and build-depend on python-central (= 0.6) instead. Thanks for reporting this. This bug was fixed in SVN. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460419: omniorb4: FTBFS on arm: segmentation fault
Hello, I am now convinced this is a g++ bug. I could reproduce the FTBFS on qemu. Trying to compile omniorb4 with g++-4.1.3 20080114 (Debian 4.1.2-19) succeeds. I will try to write a reduced test case before submitting the bug report on g++-4.2. I need to check wether g++-4.3 is affected as well. Anyway, I'll prepare an upload using g++-4.1 on arm tomorrow to fix this FTBFS. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Hello,
A while ago, I wrote:
Using the following pakages:
* java-gcj-compat{,-dev} 1.0.69-2
* ecj, ecj-gcj, libecj-java and libecj-gcj 3.3.0+0728-1
* libgcj-bc, libgcj8{-1,-1-awt,-jar} 4.2.1-3
* gcc-4.2-base 4.2.1-3
* gcj-4.1-base, gcj-4.1, gij-4.1, libgcj7-1 4.1.2-16
* libgcc1 1:4.2.2-3
eclipse-cdt compiles.
Updating to sid, I reach a point where it no longer compiles:
* java-gcj-compat 1.0.76-4 sets gcj-4.2 as the default gcj version
* gcj-4.2, gij-4.2 and libgcj8-* are at version 4.2.1-3
On Sat, Jan 26, 2008 at 05:12:44PM +0100, Michael Koch replied:
I have just tried this with SUN JDK 6, Icedtea, gcj 4.3, jamvm and cacao
with the following result:
* SUN JDK 6: Just works.
* gcj-4.3: No output at all. Returns with exit code 13.
* icedtea: No output at all. Returns with exit code 13. Exactly the same
as with gcj.
* jamvm: Fails but prints quite some output. Main issue is that jamvm has
no real JAVA_HOME.
* cacao: Fails but prints some output. Again an issue with an incomplete
JAVA_HOME provided by cacao.
We made progress on this issue with Michael; it turns out that using
eclipse natively compiled -gcj packages work around the FTBFS, for some
reason.
Michael found out that only eclipse-rcp-gcj is needed, and that deleting
org.eclipse.core.runtime_3.2.0.v20060603.jar.so is enough to make the
compilation fails, while it works when it's there.
So we now have a work-around to compile Eclipse plugins: install
eclipse-rcp-gcj.
What's really weird is that icedtea, even though it does not use -gcj
packages, exhibit the very same behavior.
Any idea on this?
Regards,
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460419: omniorb4: FTBFS on arm: segmentation fault
Hmmm... http://bugs.debian.org/458745 looks quite similar to this one. It might be related. I'll try to build omniorb4 on arm without alloca (i.e. with --disable-alloca) to see if it fixes the failure on arm. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462644: FTBFS: src/jni/gtk_java.c:15:17: error: jni.h: No such file or directory
Package: libgtk-java Version: 2.10.2-5 Severity: serious Justification: FTBFS on amd64 This is the same kind of bug as #462500 and #462506. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgtk-java depends on: ii gij [java2-runtime] 4:4.3-1The GNU Java bytecode interpreter ii gij-4.1 [java2-runtime] 4.1.2-19 The GNU Java bytecode interpreter ii gij-4.2 [java2-runtime] 4.2.2-7The GNU Java bytecode interpreter ii gij-4.3 [java2-runtime] 4.3-20080116-1 The GNU Java bytecode interpreter ii java-gcj-compat 1.0.77-3 Java runtime environment using GIJ ii libcairo-java 1.0.8-7Java bindings for Cairo ii libglib-java 0.4.2-8Java bindings for GLib ii libgtk-jni2.10.2-5 Java bindings for GTK+ (native lib Versions of packages libgtk-java recommends: ii libgtk-java-gcj 2.10.2-5 Java bindings for GTK+ (native cod -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Le samedi 26 janvier 2008 à 17:12 +0100, Michael Koch a écrit : I have just tried this with SUN JDK 6, Icedtea, gcj 4.3, jamvm and cacao with the following result: SUN JDK 6: Just works. gcj-4.3: No output at all. Returns with exit code 13. icedtea: No output at all. Returns with exit code 13. Exactly the same as with gcj. That's great Michael, because it means it should now be possible to debug this issue from within eclipse itself using icedtea! Regards, Thomas
Bug#460419: omniorb4: FTBFS on arm: segmentation fault
Hello, I have problems finding out why omniorb4 fails to build on arm[1]. Having a look at the crash with gdb I can't spot anything obvious. Could someone with an arm knowledge have a look at this please? Thanks, Thomas [1] bugs.debian.org/460419 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460419: [Pkg-corba-devel] Bug#460419: omniorb4: FTBFS on arm: segmentation fault
tags 460419 + confirmed help Selon Martin Michlmayr [EMAIL PROTECTED]: * Philipp Kern [EMAIL PROTECTED] [2008-01-12 16:41]: omniorb4 fails to build from source since 4.1.0-1 on arm and causes a compiler segmentation fault. omniidl: 'cxx' imported from '../../../../src/lib/omniORB/omniidl_be/cxx/__init__.py' omniidl: Preprocessing '../../../../idl/Naming.idl' with '/build/buildd/omniorb4-4.1.1/build/lib/omnicpp -lang-c++ -undef -D__OMNIIDL__=0x2630 -D__OMNIIDL_CXX__ ../../../../idl/Naming.idl' omniidl: Running front end make[4]: *** [omniORB4/Naming.hh] Segmentation fault make[4]: Leaving directory `/build/buildd/omniorb4-4.1.1/build/src/lib/omniORB' Our Netwinder buildds often show segfaults when compiling stuff and a rebuild helps. I'm not sure what type of machine the hedges buildd is. Aurelien, do you know? Hello, I can reproduce this on leisner. A first analysis with gdb makes me think the stack gets corrupt. The segfault occurs after stepping into a function, but before reaching first lines. Besides the very same function is called twice without segfaulting, and when inkoked a third time the crash occurs. I believe the code uses alloca(), does that raise something? Thanks for your help, Regards, Thomas
Bug#460461: gnu-smalltalk-browser: gst-blox does not work
Package: gnu-smalltalk-browser Version: 3.0-1 Severity: grave Justification: renders package unusable gst-blox does not work at all. Trying with Tk or Gtk does not change anything. strace'ing the launch reveals EACCESS on gst.im. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnu-smalltalk-browser depends on: ii gnu-smalltalk 3.0-1 GNU Smalltalk interpreter and imag ii gnu-smalltalk-common 3.0-1 GNU Smalltalk class library source ii libc6 2.7-5 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-1 Multiprecision arithmetic library ii libgst7 3.0-2 GNU Smalltalk virtual machine shar ii libgtk2-gst 3.0-1 Gtk bindings and environment for G ii libreadline5 5.2-3 GNU readline and history libraries ii libsigsegv0 2.4-4 Library for handling page faults i gnu-smalltalk-browser recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432541: eclipse-cdt FTBFS with gcj-4.2
reassign 432541 gcj-4.2
retitle 432541 gcj-4.2 can no longer compile Eclipse plugins
merge 432539 432541
thanks
Hi,
after having slowly updated an etch chroot to a sid one using
snaphsot.debian.net, I have found that the FTBFS occurs with gcj-4.2,
and is not related to ecj.
Indeed, using the following pakages:
* java-gcj-compat{,-dev} 1.0.69-2
* ecj, ecj-gcj, libecj-java and libecj-gcj 3.3.0+0728-1
* libgcj-bc, libgcj8{-1,-1-awt,-jar} 4.2.1-3
* gcc-4.2-base 4.2.1-3
* gcj-4.1-base, gcj-4.1, gij-4.1, libgcj7-1 4.1.2-16
* libgcc1 1:4.2.2-3
eclipse-cdt compiles.
Updating to sid, I reach a point where:
* java-gcj-compat 1.0.76-4 sets gcj-4.2 as the default gcj version
* gcj-4.2, gij-4.2 and libgcj8-* are at version 4.2.1-3
With these packages eclipse-cdt no longer compiles.
I'll try to use earlier versions of {gcj,gij}-4.2.
Regards,
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432539: gcj-4.2 can no longer compile Eclipse plugins
reassign 432539 gcj-4.2 merge 432539 432541 thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432541: eclipse-cdt FTBFS
Hello, On Mon, Oct 22, 2007 at 02:42:40PM +0200, Matthias Klose wrote: Thomas, please could check with gcj-4.3 (from experimental) / gcc-snapshot? With: * gcc-snapshot 20071020-1 * gij-4.3 4.3-20071020-1 I have the same problem; make stops with: make: *** [build-stamp] Error 13 I'm not even sure the build process reaches a point where gcj is called. I'll investigate further this evening. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432541: eclipse-cdt FTBFS
Hello Andrew, On Mon, Oct 22, 2007 at 11:55:43AM +0100, Andrew Haley wrote: Moving from an etch chroot to sid, I was able to find out that the following upgrades do not impact eclipse-cdt compilation: * libc6 2.6.1-6 * ant 1.7.0-3 * eclipse 3.2.2-4 This means one of the following packages is causing eclipse-cdt to FTBFS: * ecj * gij/gcj Unfortunately, these packages have to be updated at once. Any idea how to find out which one could be the culprit? gcj's class loading machanism hasn't changed. Andrew Overholt [EMAIL PROTECTED] thinks there's probably something wrong with the OSGI configuration, and the fact that the first exception also happens with Sun's VM must be a clue. I've tried again with Sun's VM and eclipse 3.2.2-4[1], and it builds fine. Has this version of Eclipse and Eclipse CDT been built successfully on Debian/gcj before now, or is it new? It built successfully in June[2], and started to fail building in July[3]. It still builds fine on etch, with updated libc6, eclipse and ant. Thanks for looking into this, Thomas [1] wich contains the following fix: debian/patches/eclipse-ant-manifest.dpatch: Don't remove ant-launcher.jar from ant plugin classpath. Needed for Ant 1.7. [2] http://buildd.debian.org/fetch.cgi?pkg=eclipse-cdt;ver=3.1.2-1;arch=amd64;stamp=1182115944 [3] http://bugs.debian.org/432541 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432541: eclipse-cdt FTBFS
Le mercredi 10 octobre 2007 à 12:36 +0200, Thomas Girard a écrit : Just another hint on this one: using etch to recompile eclipse-cdt *does* work. So it's likely a problem in the toolchain. Moving from an etch chroot to sid, I was able to find out that the following upgrades do not impact eclipse-cdt compilation: * libc6 2.6.1-6 * ant 1.7.0-3 * eclipse 3.2.2-4 This means one of the following packages is causing eclipse-cdt to FTBFS: * ecj * gij/gcj Unfortunately, these packages have to be updated at once. Any idea how to find out which one could be the culprit? Thanks, Thomas
Bug#432541: eclipse-cdt FTBFS
Just another hint on this one: using etch to recompile eclipse-cdt *does* work. So it's likely a problem in the toolchain. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444302: bouml: Since the package is built with a gcc not in Sid, it is uninstallable
tags 444302 + pending thanks On Thu, Sep 27, 2007 at 11:14:23AM -0500, Manoj Srivastava wrote: Package: bouml Version: 2.31-1 Severity: grave Since it does not install, I suppose this fits the mostly useless criteria. Please do not build against experimental gcc. Woops! Sorry about that. I'll fix this asap. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432541: eclipse-cdt FTBFS
Hello Andrew, thanks for looking into this. On Wed, Sep 12, 2007 at 08:15:47PM -0400, Andrew Overholt wrote: Try running the launcher directly: /usr/bin/eclipse -noSplash -application org.eclipse.ant.antRunner (or whatever). I think the exit in this case is due to the osgi configuration area being incorrect, but I could be wrong about that. Indeed, launching the eclipse wrapper with the following command-line: $ eclipse -debug -nosplash -application org.eclipse.ant.core.antRunner gives the attached ~/workspace/.log excerpt. Interesting part: !ENTRY org.eclipse.osgi 4 0 2007-09-18 23:31:18.175 !MESSAGE Application error !STACK 1 java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:377) at org.eclipse.core.runtime.Platform.getPlugin(Platform.java:737) at org.eclipse.core.internal.preferences.legacy.InitLegacyPreferences.init(InitLegacyPreferences.java:43) at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.applyRuntimeDefaults(PreferenceServiceRegistryHelper.java:146) at org.eclipse.core.internal.preferences.PreferencesService.applyRuntimeDefaults(PreferencesService.java:337) at org.eclipse.core.internal.preferences.DefaultPreferences.applyRuntimeDefaults(DefaultPreferences.java:162) Launching eclipse using extra magic found in eclipse(1): $ eclipse -application org.eclipse.ant.core.antRunner -noSplash -debug -dev /usr/lib/eclipse/plugins/org.eclipse.core.runtime_3.2.0.v20060603.jar fails elsewhere with another class not found exception. Looking and adding jars to the comma separated list following -dev argument eventually fails with: !ENTRY org.eclipse.core.runtime 4 0 2007-09-19 00:07:35.642 !MESSAGE FrameworkEvent.ERROR !STACK 0 org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.runtime.PlatformActivator.start() of bundle org.eclipse.core.runtime. [...] Caused by: java.lang.ClassCastException: org.eclipse.core.runtime.internal.adaptor.EclipseEnvironmentInfo cannot be cast to org.eclipse.osgi.service.environment.EnvironmentInfo I though something could be broken in the eclipse package (see also #432539), but I am able to reproduce the first ClassNotFoundException using upstream Eclipse tarball. Has something changed in gij's class loading mechanism? Regards, Thomas !SESSION 2007-09-19 00:19:21.564 --- eclipse.buildId=M20070212-1330 java.fullversion=GNU libgcj 4.2.1 (Debian 4.2.1-5) BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=fr_FR Framework arguments: -application org.eclipse.ant.core.antRunner Command-line arguments: -os linux -ws gtk -arch x86_64 -debug -application org.eclipse.ant.core.antRunner !ENTRY org.eclipse.osgi 2 1 2007-09-19 00:19:24.128 !MESSAGE NLS missing message: initializer_error in: org.eclipse.core.internal.runtime.messages !ENTRY org.eclipse.osgi 2 1 2007-09-19 00:19:24.128 !MESSAGE NLS missing message: fileInitializer_fileNotFound in: org.eclipse.core.internal.runtime.messages !ENTRY org.eclipse.osgi 2 1 2007-09-19 00:19:24.128 !MESSAGE NLS missing message: fileInitializer_IOError in: org.eclipse.core.internal.runtime.messages !ENTRY org.eclipse.osgi 2 1 2007-09-19 00:19:24.128 !MESSAGE NLS missing message: fileInitializer_missingFileName in: org.eclipse.core.internal.runtime.messages !ENTRY org.eclipse.osgi 4 0 2007-09-19 00:19:24.173 !MESSAGE Application error !STACK 1 java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:377) at org.eclipse.core.runtime.Platform.getPlugin(Platform.java:737) at org.eclipse.core.internal.preferences.legacy.InitLegacyPreferences.init(InitLegacyPreferences.java:43) at org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.applyRuntimeDefaults(PreferenceServiceRegistryHelper.java:146) at org.eclipse.core.internal.preferences.PreferencesService.applyRuntimeDefaults(PreferencesService.java:337) at org.eclipse.core.internal.preferences.DefaultPreferences.applyRuntimeDefaults(DefaultPreferences.java:162) at org.eclipse.core.internal.preferences.DefaultPreferences.loadDefaults(DefaultPreferences.java:231) at org.eclipse.core.internal.preferences.DefaultPreferences.load(DefaultPreferences.java:227) at
Bug#432541: eclipse-cdt FTBFS
tags 432541 + help thanks I'm really stuck with this one. This eclipse-cdt FTBFS is always reproducible on amd64 and i386; I have not tried on other platforms. Trying to build eclipse-cdt leads to: cd source-tree/org.eclipse.cdt.releng \ /usr/lib/jvm/java-gcj/bin/java -cp /usr/lib/eclipse/startup.jar \ -Dosgi.sharedConfiguration.area=/usr/lib/eclipse/configuration \ -Duser.home=/home/tgg/src/eclipse-cdt-3.1.2/home \ org.eclipse.core.launcher.Main \ -application org.eclipse.ant.core.antRunner \ -DjavacFailOnError=true \ -DdontUnzip=true \ -DbaseLocation=/usr/lib/eclipse \ -Dpde.build.scripts=/usr/lib/eclipse/plugins/org.eclipse.pde.build_3.2.1.r321_v20060823/scripts \ -DdontFetchAnything=true \ -Dconfigs=linux,gtk,x86 \ -Dbaseos=linux \ -Dbasews=gtk \ -Dbasearch=x86 make: *** [build-stamp] Error 13 Replacing gij with Sun's VM produces the very same error, but adding /usr/share/java/ant-launcher.jar before /usr/lib/eclipse/startup.jar makes the compilation work like a charm. Unfortunately this does not change anything for gij... Looking for System.exit(13) in eclipse's code does reveal: plugins/org.eclipse.osgi/eclipseAdaptor/src/org/eclipse/core/runtime/internal/adaptor/EclipseErrorHandler.java:88 which is inside handleRuntimeError(). But I have not been able to attach a debugger to see what's the root cause of this, so I can't tell if it's relevant. Does anybody know how to dig a little further? Thanks, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440088: libstlport5.1-dev: single-thread namespace for thread-safe library
severity 440088 wishlist retitle 440088 libstlport5.1-dev: could warn again inconsistent threading flags thanks Hello Jason, On Wed, Aug 29, 2007 at 11:37:45AM -0500, Jason Kraftcheck wrote: The headers included in libstlport5.1-dev define _STDP_STD_NAME to be the non-thread-safe namespace (stlpmtx_std). The library installed by libstlport5.1 includes only symbols in the thread-safe namespace (stlp_std.) The following code will print out the definitino of _STDP_STD_NAME as defined in /usr/include/stlport/std/config/features.h: [snip] The output I get is stlpmtx_std. The following command will list the symbols defined in the libary: nm -CD --defined-only /usr/lib/libstlport5.1 The library appears to define everythign in the stlp_std namespace. If you compile your sample program with `-pthread' and run it again you'll see the macro gets expanded to `stlp_std'. This flag has to be used whenever compiling a program using libstlport5.1 - it's written in /usr/share/doc/libstlport5.1-dev/README.Debian. But maybe stl/config/features.h could #warn about inconsistent threading flags? I'll leave this bug open as a remainder. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436177: I think the problem is in gcj
reassign 436177 glibc forcemerge 434484 436177 thanks On Wed, Aug 08, 2007 at 10:25:24PM +0200, Manolo Díaz wrote: I've experienced a similar problem trying to launch freemind [...] In my system /usr/bin/java is provided by the package gij-4.1 (version 4.1.1-20). This problem is known (see #433391 and #434484) and was fixed with the upload of glibc 2.6.1-1. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432541: eclipse-cdt: FTBFS: java.lang.NullPointerException at org.eclipse.core.internal.jobs.Worker.run(Worker.java:84)
tags 432541 + confirmed thanks Hi Lucas, Le mardi 10 juillet 2007 à 12:10 +, Lucas Nussbaum a écrit : Package: eclipse-cdt version: 3.1.2-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20070708 Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. [...] The full build log is available from http://people.debian.org/~lucas/logs/2007/07/08/ I can reproduce this, thanks for reporting. I'll have a look asap. Regards, Thomas
Bug#425959: [Pkg-ace-devel] Bug#425959: ace: FTBFS: error: operator '=' has no left operand
Hi Lucas, thanks for reporting this. On Thu, May 24, 2007 at 06:53:18PM +0200, Lucas Nussbaum wrote: Package: ace version: 5.4.7-12 Severity: serious Justification: FTBFS on i386 During a rebuild of all packages in sid, your package failed to build on i386. A rebuild from a clean, up-to-date sid pbuilder does not trigger this FTBFS. I'll need to dig a little further. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426510: GNU Smalltalk 2.3.4-1 FTBFS
Package: gnu-smalltalk Version: 2.3.4-1 Severity: serious GNU Smalltalk 2.3.4-1 FTBFS on all arches because a file needs to be regenerated during compilation, and this fails. I'm working on a fix. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424470: libgconf-java - FTBFS: Package cairo was not found in the pkg-config search path
tags 424470 + confirmed pending block 424470 by 423525 thanks On Wed, May 16, 2007 at 09:10:00AM +0200, Michael Ablassmeier wrote: Package: libgconf-java Version: 2.12.6-2 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs hi, while doing an archive wide package rebuild your package failed to build from source for the following reason: checking if gcj PIC flag -fPIC works... yes checking if gcj static flag -static works... no checking if gcj supports -c -o file.o... yes checking whether the gcj linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GTKJAVA... configure: error: Package requirements (gtk2-java = 2.10) were not met: Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containing `cairo.pc' to the PKG_CONFIG_PATH environment variable Package 'cairo', required by 'Cairo-Java', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables GTKJAVA_CFLAGS and GTKJAVA_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [config.status] Error 1 Hello, Thanks for reporting this. this is actually a consequence of #423525; I'm working on a fix. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423843: libgconf-java - FTBFS: Package cairo was not found in the pkg-config search path.
reassign 423843 libgconf-java forcemerge 424479 423843 thanks I've changed my mind again, this bug is really for libgconf-java. Merging it with the newly reported bug. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423843: libgconf-java - FTBFS: Package cairo was not found in the pkg-config search path.
reassign 423843 libgtk-java tag 423843 + pending thanks Hi, On Mon, May 14, 2007 at 03:53:19PM +0200, Bastian Blank wrote: Package: libgconf-java Version: 2.12.6-2 Severity: serious There was an error while trying to autobuild your package: Automatic build of libgconf-java_2.12.6-2 on debian-31.osdl.marist.edu by sbuild/s390 98 [...] checking pkg-config is at least version 0.9.0... yes checking for GTKJAVA... configure: error: Package requirements (gtk2-java = 2.10) were not met: Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containing `cairo.pc' to the PKG_CONFIG_PATH environment variable Package 'cairo', required by 'Cairo-Java', not found This is in fact an error in gtk2-java.pc file which incorrectly requires gtk+-2.0. The next upload of libgtk-java will fix this. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423523: lib{glib,cairo}-jni: Missing Depends.
Hello Kurt, thanks for reporting: On Sat, May 12, 2007 at 05:30:42PM +0200, Kurt Roeckx wrote: Package: libglib-jni Version: 0.4.2-6 Severity: serious The /usr/lib/pkgconfig/glib-java.pc file says: Requires: glib-2.0 gobject-2.0 So you need a Depends on libglib2.0-dev which provided both of those. and: Package: libcairo-jni Version: 1.0.8-4 Severity: serious The /usr/lib/pkgconfig/cairo-java.pc file says: Requires: cairo glib-java So you need a Depends: - libcairo2-dev - libglib-java You are right for libglib-jni. I am annoyed that installing a -jni package pulls in -dev package. Maybe I should have put headers, .so symlink and .pc into a separate package, e.g. lib$p-jni-dev? There are already five binary package for every Java-Gnome source package, so that's maybe too much to add another one. For libcairo-jni, I agree with the dependency on libglib-java, but I am not sure for the dependency on libcairo2-dev: libcairo-jni does not contain any header requiring another one from libcairo2-dev. That might be an error in the .pc file. I need to think about these problems again, thanks for pointing this out. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421454: shlibs broken for binutils
Package: binutils Version: 2.17cvs20070426-2 Severity: serious Hello, the shlibs of binutils reads: libbfd 2.17 binutils libopcodes 2.17 binutils while: libbfd soname is libbfd-2.17.50.20070426.so libopcodes soname is libopcodes-2.17.50.20070426.so The shlibs sould probably be updated. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420052: libgtk-java: FTBFS: 3 errors, 77 warnings during build
tags 420052 + confirmed pending
thanks
Hello Lucas,
On Thu, Apr 19, 2007 at 07:01:50PM +0200, Lucas Nussbaum wrote:
Package: libgtk-java
Version: 2.8.5-1.2
Severity: serious
Justification: FTBFS on i386, very likely to fail everywhere else
Usertags: grid5000 rebuild
Hi,
During a rebuild of all packages in sid, I discovered that your package
failed to build on i386.
Relevant parts:
gcj -C -classpath
/usr/share/java/glib0.4-0.4.2.jar:/usr/share/java/cairo1.0-1.0.8.jar:src/java:./src/java
-d src/java src/java/org/gnu/glib/GObject.java
src/java/org/gnu/glib/GObject.java:20: warning: The class
'org.gnu.glib.Struct' has been deprecated.
public class GObject extends Struct {
[]
3 errors, 77 warnings
make[1]: *** [src/java/org/gnu/glib/GObject.class] Error 1
Thanks for reporting this.
The libgtk-java distributed GObject.java had modifications over the one
from glib-java. Those modifications were merged back into glib-java;
from libgtk-java 2.9.1 on this file is no longer distributed along with
libgtk-java.
The problem here is that the Debian glib-java is up-to-date while
libgtk-java is not. I am currently updating all the Java Gnome 2.x
libraries and this issue will disappear when I'm done.
Regards,
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415637: gnu-smalltalk_2.3.3-2(experimental/ia64/alkman):
On Tue, Mar 20, 2007 at 11:36:02PM +0100, Marc 'HE' Brockschmidt wrote: Heya, Hi Marc, Building gnu-smalltalk on ia64 failed: [...] | config.status: linking ./src/ia64/ffitarget.h to include/ffitarget.h | config.status: error: ./src/ia64/ffitarget.h: file not found | configure: error: ./configure failed for libffi | make: *** [configure-stamp] Error 1 The libffi/src/ia64/ffitarget.h is indeed missing in the smalltalk tarball. It is available in upstream's arch repo, so I'll report this issue upstream. Thanks, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410554: stlport5.1_5.1.0-1(experimental/alpha/ds10): error: size of array '__static_assert' is negative
Hi, thanks for reporting. On Sun, Feb 11, 2007 at 07:21:09PM +0100, Marc 'HE' Brockschmidt wrote: Package: stlport5.1 Version: 5.1.0-1 Severity: serious Tags: experimental Heya, stlport5.1 failed to build on alpha: [...] ../../stlport/stl/_cwchar.h:114: error: size of array '__static_assert' is negative This reminds me of a previous patch, possibly disabled. I'll have a look at next week. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392131: broken libstlport.so symlink
Hi Rene, Selon Rene Engelhard [EMAIL PROTECTED]: Package: libstlport5.0-dev Version: 5.0.2-10 Severity: grave $ ls -l /usr/lib/libstlport.so lrwxrwxrwx 1 root root 15 2006-10-10 15:26 /usr/lib/libstlport.so - libstlport.so.5 which of course doesn't exist, but what exists is $ ls -l /usr/lib/libstlport.so.5.0 lrwxrwxrwx 1 root root 19 2006-10-10 14:24 /usr/lib/libstlport.so.5.0 - libstlport.so.5.0.2 This breaks OOo builds (I can work around it here but not on the buildds) and I need to get another upload into etch before the freeze so please fix ASAP, Ouch ! Sorry about that. I have commited a fix for this and I am currently testing it. stlport5.1 is affected as well. Thomas
Bug#390975: libstlport5.1: can't install
tags 390975 + confirmed thanks Hi, $ sudo apt-get install libstlport5.1 Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed libstlport5.1 0 upgraded, 1 newly installed, 0 to remove and 872 not upgraded. Need to get 0B/211kB of archives. After unpacking 709kB of additional disk space will be used. (Reading database ... 273830 files and directories currently installed.) Unpacking libstlport5.1 (from .../libstlport5.1_5.0.99rc2-5_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libstlport5.1_5.0.99rc2-5_amd64.deb (--unpack): trying to overwrite `/usr/lib/libstlport.so.5', which is also in package libstlport5.0 Errors were encountered while processing: /var/cache/apt/archives/libstlport5.1_5.0.99rc2-5_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) I can reproduce this, thanks for reporting. I'm investigating why (and when) this symlink appeared. Thomas
Bug#389316: stlport5.1_5.0.99rc2-4(hppa/unstable): FTBFS: links without arch-specific stdlibs
Hi, Selon [EMAIL PROTECTED]: Package: stlport5.1 Version: 5.0.99rc2-4 Severity: serious architectures are allowed to have specific standard libraries, and linking without them is fatal. There was an error while trying to autobuild your package: Automatic build of stlport5.1_5.0.99rc2-4 on bld-3 by sbuild/hppa 85 Build started at 20060921-1545 [...] ** Using build dependencies supplied by package: Build-Depends: cdbs, debhelper (= 4.1.0), dpkg-dev (= 1.13.19), quilt [...] ../../../stlport/stl/_hashtable.h:634: undefined reference to `$$remU' ../../../stlport/stl/_hashtable.h:634: undefined reference to `$$remU' ../../../stlport/stl/_hashtable.h:634: undefined reference to `$$remU' obj/gcc/so/unordered_test.o:../../../stlport/stl/_hashtable.h:634: more undefined references to `$$remU' follow obj/gcc/so/unordered_test.o: In function `UnorderedTest::myRun(char const*, bool)': ../../../test/unit/unordered_test.cpp:26: undefined reference to `$$dyncall' ../../../test/unit/unordered_test.cpp:26: undefined reference to `$$dyncall' ../../../test/unit/unordered_test.cpp:26: undefined reference to `$$dyncall' ../../../test/unit/unordered_test.cpp:27: undefined reference to `$$dyncall' ../../../test/unit/unordered_test.cpp:27: undefined reference to `$$dyncall' obj/gcc/so/unordered_test.o:../../../test/unit/unordered_test.cpp:27: more undefined references to `$$dyncall' follow collect2: ld returned 1 exit status make[1]: *** [obj/gcc/so/stl_unit_test] Error 1 make[1]: Leaving directory `/build/buildd/stlport5.1-5.0.99rc2/build/test/unit' make: *** [common-binary-post-install-arch] Error 2 The very same error used to happen for stlport5. The fix was to add -lgcc to link the static library that contains those symbols on hppa. As stlport5 provides a STL replacement it is linked with -nostdlib. I'll have a look at this tonight, if Twerner has not already fixed it by then. Thanks, Thomas
Bug#384585: manedit: crashes with autogenerated rc file
Selon Nacho Barrientos Arias [EMAIL PROTECTED]:
(gdb) print style_ptr-font
$2 = (GdkFont *) 0x7083d0
(gdb) next
(gdb) print style_ptr-font
Is it NULL now?
Yes,
(gdb) next
170 style_ptr = styles_list-edit_text_background;
(gdb) print style_ptr-font
$3 = (GdkFont *) 0x0
Great, thanks. Could you please try the attached patch? It tries to
avoid the problem you're facing.
Thomas--- prefop.c- 2006-09-13 07:54:20.0 +
+++ prefop.c 2006-09-13 07:58:01.0 +
@@ -156,10 +156,12 @@
*/
#define DO_APPLY_ENTRY_FONT_NAME { \
if((font_name != NULL) (style_ptr != NULL)) { \
- if(style_ptr-font != NULL)\
- gdk_font_unref(style_ptr-font); \
- style_ptr-font = gdk_font_load(font_name); \
-} }
+ GdkFont *new_font = gdk_font_load(font_name); \
+ if(new_font != NULL) {\
+ if(style_ptr-font != NULL)\
+ gdk_font_unref(style_ptr-font); \
+ style_ptr-font = new_font;\
+} } }
/* Font editable text */
font_name = (gchar *)PrefParmGetValueP(
Bug#384585: manedit: crashes with autogenerated rc file
Nacho Congratulations, i applied it to a clean source tree and it works for Nacho me. Now, i can execute Manedit with an existing RC file. Great! So the previous patch manedit.diff is not needed? I believe drag and drop could crash without it, but this is not related to this bug. Me Heck. Here's the patch. Oh well. My webmail is hiding attachments. Sorry for the duplicate. Thomas
Bug#384585: manedit: crashes with autogenerated rc file
Selon Thomas Girard [EMAIL PROTECTED]:
Great, thanks. Could you please try the attached patch? It tries to
avoid the problem you're facing.
Heck. Here's the patch.--- prefop.c- 2006-09-13 07:54:20.0 +
+++ prefop.c 2006-09-13 07:58:01.0 +
@@ -156,10 +156,12 @@
*/
#define DO_APPLY_ENTRY_FONT_NAME { \
if((font_name != NULL) (style_ptr != NULL)) { \
- if(style_ptr-font != NULL)\
- gdk_font_unref(style_ptr-font); \
- style_ptr-font = gdk_font_load(font_name); \
-} }
+ GdkFont *new_font = gdk_font_load(font_name); \
+ if(new_font != NULL) {\
+ if(style_ptr-font != NULL)\
+ gdk_font_unref(style_ptr-font); \
+ style_ptr-font = new_font;\
+} } }
/* Font editable text */
font_name = (gchar *)PrefParmGetValueP(
Bug#384585: manedit: crashes with autogenerated rc file
Hi Nacho, On Wed, Sep 06, 2006 at 10:56:03AM +0200, Nacho Barrientos Arias wrote: Yes, style-font is NULL. Okay, thanks. I don't understand why it gets NULL. From what I've seen, the culprit style is stored in the field edit_text_standard. It is first set in main.c:398, then in prefop.c:169 with the content of what was retrieved from the .maneditrc. Could you please try with gdb to display the style content around those lines? On the binary built with debugging symbols, that would give something like: (gdb) b main.c:398 Breakpoint 1 at ...: file main.c, line 398. (gdb) r Breakpoint 1, ... (gdb) print style_ptr-font This value should not be NULL (gdb) b prefop.c:169 Breakpoint 2 at ...: file prefop.c, line 169. (gdb) cont Breakpoint 2, ... (gdb) print style_ptr-font What does it read? (gdb) next (gdb) print style_ptr-font Is it NULL now? Thanks, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386713: TAO programs use dlopen() on symlink rather than soname
Package: ace Version: 5.4.7-10 Severity: grave Justification: renders package unusable Hi, I've just realised that some TAO functionalities (e.g. codesets, portable interceptors) get dlopen()'ed using the library symlink instead of the soname. Therefore it is not possible to use many TAO programs without installing libtao-dev (and maybe libtao-orbsvcs-dev) package first. I'm working on a fix. Thanks, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384585: manedit: crashes with autogenerated rc file
Hi, On Sun, Sep 03, 2006 at 01:54:18AM +0200, Nacho Barrientos Arias wrote: Program received signal SIGSEGV, Segmentation fault. 0x2b9f5159a3f0 in gtk_paint_hline () from /usr/lib/libgtk-1.2.so.0 (gdb) bt full #0 0x2b9f5159a3f0 in gtk_paint_hline () from /usr/lib/libgtk-1.2.so.0 No symbol table info available. #1 0x2b9f5159aaa1 in gtk_style_attach () from /usr/lib/libgtk-1.2.so.0 No symbol table info available. #2 0x2b9f515c8390 in gtk_widget_size_request () from /usr/lib/libgtk-1.2.so.0 No symbol table info available. #3 0x00423710 in EditorNew (core_ptr=0x6c9010) at editor.c:2851 I'm sorry, I can't find that code path. editor.c:2851 should call gtk_widget_set_style(), but maybe it is inlined? Another try: could you please install libgtk1.2-dbg package, then export your LD_LIBRARY_PATH to /usr/lib/debug before running gdb again and send the output of bt full? Thanks, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384585: manedit: crashes with autogenerated rc file
On Tue, Sep 05, 2006 at 09:06:18PM +0200, Nacho Barrientos Arias wrote:
#0 0x2b78e4d943f0 in gtk_style_init (style=0x826780, colormap=0x6dd870,
depth=value optimized out)
at gtkstyle.c:657
gc_values = {foreground = {pixel = 7150384, red = 0, green = 0, blue
= 0}, background = {pixel = 25167021,
red = 4, green = 130, blue = 0}, font = 0x0, function = GDK_COPY,
fill = GDK_SOLID, tile = 0x0, stipple = 0x0,
clip_mask = 0x824e70, subwindow_mode = 3841190889, ts_x_origin = 11128,
ts_y_origin = 0, clip_x_origin = 0,
clip_y_origin = 8541904, graphics_exposures = 0, line_width = 8539760,
line_style = GDK_LINE_SOLID,
cap_style = 4753056, join_style = GDK_JOIN_MITER}
i = value optimized out
__PRETTY_FUNCTION__ = gtk_style_init
Thanks, we're getting closer. Can you please do the same thing again and
when it has crashed type print *style then if it's not NULL print
style-font?
style-font or style-font-type should be NULL. If it is, then we have
found the culprit and we can start investigating. It it's not then I'm
stuck.
Thanks,
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384507: libnsuml-java: FTBFS: You must specify a valid JAVA_HOME or JAVACMD!
tags 384507 + patch thanks Hi, On Thu, Aug 24, 2006 at 09:14:47PM +0200, Aurelien Jarno wrote: dpkg-source: extracting libnsuml-java in libnsuml-java-0.4.20 dpkg-buildpackage: source package is libnsuml-java dpkg-buildpackage: source version is 0.4.20-12 dpkg-buildpackage: host architecture i386 dpkg-buildpackage: source version without epoch 0.4.20-12 /usr/bin/fakeroot debian/rules clean test -x debian/rules test `id -u` = 0 dh_clean You must specify a valid JAVA_HOME or JAVACMD! make: *** [ant-sanity-check] Error 1 As debian/rules sets JAVA_HOME to /usr/lib/kaffe, kaffe has to be added as a build-dependency. The attached patch fixes this, and also corrects Build-Depends/Build-Depends-Indep. This package would probably need to be updated to use java-gcj-compat. Thomas --- debian/control- 2006-09-02 11:48:57.486717000 +0200 +++ debian/control 2006-09-02 12:31:45.403201750 +0200 @@ -3,7 +3,8 @@ Priority: optional Maintainer: Debian Java Maintainers pkg-java-maintainers@lists.alioth.debian.org Uploaders: Arnaud Vandyck [EMAIL PROTECTED] -Build-Depends-Indep: debhelper ( 4.0.0), cdbs (= 0.4.21), jikes-kaffe (= 2:1.1.5), ant, libdtdparser-java (= 1.21), libjdom0-java (= 0.7b.20020216-3) +Build-Depends: debhelper ( 4.0.0), cdbs (= 0.4.21), kaffe (= 2:1.1.5), ant +Build-Depends-Indep: jikes-kaffe (= 2:1.1.5), libdtdparser-java (= 1.21), libjdom0-java (= 0.7b.20020216-3) Standards-Version: 3.6.2 Package: libnsuml-java
Bug#355793: jikes-sun: doesn't work with sun-j2sdk1.5 due to location of rt.jar
tags 355793 + patch
thanks
Hi,
the attached patch fixes this bug.
Thomas
--- src/jikes-sun- 2006-09-02 13:17:09.817467000 +0200
+++ src/jikes-sun 2006-09-02 13:17:44.899659500 +0200
@@ -6,6 +6,10 @@
JPATH=/usr/lib/j2${path_type}${version}-sun/lib
break 2
fi
+ if [ -e /usr/lib/j2${path_type}${version}-sun/jre/lib/rt.jar ];
then
+ JPATH=/usr/lib/j2${path_type}${version}-sun/jre/lib
+ break 2
+ fi
done
done
Bug#382491: lmms: segfaults on startup
Hi, at last I have reproduced this bug on my sid i386 box. lmms seems to parse (at least) every .xml file in the directory it was launched from. Filling a xml file with junk reproduces the crash for me, e.g.: [EMAIL PROTECTED]:~$ echo whatever whatever.xml [EMAIL PROTECTED]:~$ lmms I'm trying to find out why. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384585: manedit: crashes with autogenerated rc file
Hello,
I can't reproduce this problem on my i386 box. But according to the
report, the bug can only be seen on an amd64. Having a look at the
buildd log[1] reveals that gcc complains a log about cast to pointer
from integer of different size.
Having a look at the source code shows that it indeed relies on pointers
being 32 bits, e.g. manedit/editordnd.c EditorDNDParseCmd function reads
pointers assuming they are guint32.
The attached patch tries to correct those warnings. I have asked
someone with an AMD64 box to try to reproduce the bug with and whithout
this patch, but he was not able to reproduce it in *both* cases.
Can you please try it?
Thanks,
Thomas
[1]
http://buildd.debian.org/fetch.php?pkg=maneditver=0.6.1-2arch=amd64stamp=1148185328file=logas=raw
diff -rN -u old-manedit-0.6.1/manedit/editordnd.c
new-manedit-0.6.1/manedit/editordnd.c
--- old-manedit-0.6.1/manedit/editordnd.c 2006-09-02 18:43:13.0
+0200
+++ new-manedit-0.6.1/manedit/editordnd.c 2006-09-02 18:43:13.0
+0200
@@ -104,7 +104,7 @@
GtkCTreeNode ***branch, gint *total_branches
)
{
- guint32 addr_val;
+ gpointer addr_val;
gint i, n, strc;
gchar **strv;
@@ -131,7 +131,7 @@
/* Get editor_ptr (format in hex with no 0x prefix) */
if(strc 0)
- i = sscanf(strv[0], %x, (guint32 *)addr_val);
+ i = sscanf(strv[0], %p, addr_val);
else
i = 0;
if((i 0) (editor_ptr != NULL))
@@ -164,7 +164,7 @@
}
else
{
- i = sscanf(cs, %x, (guint32 *)addr_val);
+ i = sscanf(cs, %p, addr_val);
if(i 0)
(*branch)[n] = (GtkCTreeNode *)addr_val;
else
@@ -950,14 +950,14 @@
*/
if(branch_ptr != NULL)
buf = g_strdup_printf(
- %.8x %.8x,
- (guint32)editor,
- (guint32)branch_ptr
+ %p %p,
+ (gpointer)editor,
+ (gpointer)branch_ptr
);
else
buf = g_strdup_printf(
-%.8x,
- (guint32)editor
+%p,
+ (gpointer)editor
);
/* Send out data */
diff -rN -u old-manedit-0.6.1/manedit/editorfio.c
new-manedit-0.6.1/manedit/editorfio.c
--- old-manedit-0.6.1/manedit/editorfio.c 2006-09-02 18:43:13.0
+0200
+++ new-manedit-0.6.1/manedit/editorfio.c 2006-09-02 18:43:13.0
+0200
@@ -470,7 +470,7 @@
mp_header_struct *mp_header
)
{
- gint i;
+ size_t i;
const gchar *line;
gchar *new_line;
diff -rN -u old-manedit-0.6.1/manedit/fb.c new-manedit-0.6.1/manedit/fb.c
--- old-manedit-0.6.1/manedit/fb.c 2006-09-02 18:43:13.0 +0200
+++ new-manedit-0.6.1/manedit/fb.c 2006-09-02 18:43:13.0 +0200
@@ -527,7 +527,7 @@
#endif
#define OBJISSEL(fb,n) fb) != NULL) ((n) = 0)) ? \
- ((g_list_find(fb-selection, (gpointer)(n)) != NULL) ? TRUE : FALSE) : FALSE)
+ ((g_list_find(fb-selection, GINT_TO_POINTER((n))) != NULL) ? TRUE : FALSE) :
FALSE)
#define FB_WIDTH 480
@@ -665,7 +665,7 @@
/* Iterate through selection */
for(glist = selection; glist != NULL; glist = g_list_next(glist))
{
- i = (gint)glist-data;
+ i = GPOINTER_TO_INT(glist-data);
if((i = 0) (i total))
o = object[i];
else
@@ -1776,7 +1776,7 @@
/* Select this object */
fb-focus_object = i;
fb-selection = g_list_append(
- fb-selection, (gpointer)i
+ fb-selection, GINT_TO_POINTER(i)
);
fb-selection_end = g_list_last(fb-selection);
@@ -4081,7 +4081,7 @@
glist = g_list_next(glist)
)
{
- o = FileBrowserGetObject(fb, (gint)glist-data);
+ o = FileBrowserGetObject(fb, GPOINTER_TO_INT(glist-data));
if((o != NULL) ? (o-name != NULL) : FALSE)
{
s = strinsstr(s, -1, o-name);
@@ -4860,11 +4860,11 @@
{
if(!OBJISSEL(fb, n))
fb-selection = g_list_append(
- fb-selection, (gpointer)n
+ fb-selection, GINT_TO_POINTER(n)
);
if(!OBJISSEL(fb, i))
fb-selection = g_list_append(
- fb-selection, (gpointer)i
+ fb-selection, GINT_TO_POINTER(i)
);
fb-selection_end = g_list_last(fb-selection);
Bug#384585: manedit: crashes with autogenerated rc file
Hi again, On Sun, Sep 03, 2006 at 01:12:06AM +0200, Nacho Barrientos Arias wrote: Done. I just applied the attached patch to a clean 0.6.1-2 source tree and compiled it in a clean SID chroot. It crashes in the same way. --- 8 --- [EMAIL PROTECTED]: ~ $ rm .maneditrc [EMAIL PROTECTED]: ~ $ manedit [EMAIL PROTECTED]: ~ $ manedit ManEdit triggered a segmentation fault (1 times) ManEdit triggered a segmentation fault (2 times) ManEdit triggered a segmentation fault (3 times) ManEdit attempting immediate process exit(). --- 8 --- I'm available for all the required debug operations. Can you please recompile this patched version with debug info (setting the DEB_BUILD_OPTIONS environment variable to noopt,nostrip should do) then send here the output of bt full in gdb? Thanks, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384585: manedit: crashes with autogenerated rc file
On Sun, Sep 03, 2006 at 01:39:52AM +0200, Nacho Barrientos Arias wrote: Can you please recompile this patched version with debug info (setting the DEB_BUILD_OPTIONS environment variable to noopt,nostrip should do) then send here the output of bt full in gdb? Running as suggested above: DEB_BUILD_OPTIONS=noopt,nostrip dpkg-buildpackage -rfakeroot -us -uc According to debug information, Manedit has been compiled with this CFLAGS: -g -O0 -Wall -fno-strict-aliasing -DHAVE_GZIP -DHAVE_BZIP2 `gtk-config --cflags` -DPREFIX=\/usr\ -DLOCALBASE=\/usr\ -DX11BASE=\/usr/X11R6\ And «bt full» shows: (gdb) bt full #0 0x2b1540b103f0 in gtk_paint_hline () from /usr/lib/libgtk-1.2.so.0 No symbol table info available. #1 0x2b1540b10aa1 in gtk_style_attach () from /usr/lib/libgtk-1.2.so.0 No symbol table info available. #2 0x2b1540b3e390 in gtk_widget_size_request () from /usr/lib/libgtk-1.2.so.0 No symbol table info available. #3 0x00423710 in EditorNew () No symbol table info available. #4 0x0045fe17 in MEditInit () No symbol table info available. #5 0x004610a6 in main () No symbol table info available. Well, somehow that did not work. Can you please retry with path_where_you_build/manedit-0.6.1/manedit/manedit? Thomas
Bug#382491: lmms: segfaults on startup
tags 382491 + patch
thanks
On Sat, Sep 02, 2006 at 11:12:24PM +0200, Thomas Girard wrote:
I'm trying to find out why.
That's a chicken-egg problem. fileItem::fileItem tries to find the
file type before storing the associated pixmap (file_browser.cpp:824),
but the determineFiletype() will need this pixmap when displaying the
error.
Initialising the pixmap to NULL fixes the problem. The patch is
attached.
Thomas
--- src/core/file_browser.cpp- 2006-09-03 01:46:02.001553000 +0200
+++ src/core/file_browser.cpp 2006-09-03 01:51:04.780475500 +0200
@@ -824,6 +824,7 @@
fileItem::fileItem( Q3ListView * _parent, const QString _name,
const QString _path ) :
Q3ListViewItem( _parent, _name ),
+ m_pix( NULL ),
m_path( _path )
{
determineFileType();
@@ -837,6 +838,7 @@
fileItem::fileItem( Q3ListViewItem * _parent, const QString _name,
const QString _path ) :
Q3ListViewItem( _parent, _name ),
+ m_pix( NULL ),
m_path( _path )
{
determineFileType();
Bug#384220: ekiga: FTBFS: missing build-dep on libebook
tags 384220 + patch thanks Hi, Indeed, the libebook1.2-dev build-depends is missing. The attached patch fixes this. Thomas --- debian/control- 2006-08-31 23:46:18.686698500 +0200 +++ debian/control 2006-08-31 23:47:00.981341750 +0200 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Kilian Krause [EMAIL PROTECTED] Uploaders: Jose Carlos Garcia Sogo [EMAIL PROTECTED], Debian GNOME Maintainers [EMAIL PROTECTED], Akira TAGOH [EMAIL PROTECTED], Andreas Rottmann [EMAIL PROTECTED], Andrew Lau [EMAIL PROTECTED], Clément Stenac [EMAIL PROTECTED], Dafydd Harries [EMAIL PROTECTED], Guilherme de S. Pastore [EMAIL PROTECTED], Gustavo Franco [EMAIL PROTECTED], Gustavo Noronha Silva [EMAIL PROTECTED], J.H.M. Dassen (Ray) [EMAIL PROTECTED], Jordi Mallach [EMAIL PROTECTED], Jose Carlos Garcia Sogo [EMAIL PROTECTED], Josselin Mouette [EMAIL PROTECTED], Loic Minier [EMAIL PROTECTED], Marc 'HE' Brockschmidt [EMAIL PROTECTED], Marco Cabizza [EMAIL PROTECTED], Ondřej Surý [EMAIL PROTECTED], Ross Burton [EMAIL PROTECTED], Sebastien Bacher [EMAIL PROTECTED], Sjoerd Simons [EMAIL PROTECTED], Takuo KITAME [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.1.34), gettext, libgnome2-dev, libldap2-dev, libpt-dev (= 1.10.1), libopal-dev (= 2.2.2), libgconf2-dev, libgnomeui-dev, libsdl1.2-dev, dpatch, autotools-dev, gnome-pkg-tools, scrollkeeper, automake1.7, intltool, libxml-parser-perl, evolution-data-server-dev, gnome-doc-utils, libavahi-client-dev (= 0.6.0), libavahi-glib-dev (= 0.6.0) +Build-Depends: debhelper (= 4.1.34), gettext, libgnome2-dev, libldap2-dev, libpt-dev (= 1.10.1), libopal-dev (= 2.2.2), libgconf2-dev, libgnomeui-dev, libsdl1.2-dev, dpatch, autotools-dev, gnome-pkg-tools, scrollkeeper, automake1.7, intltool, libxml-parser-perl, evolution-data-server-dev, gnome-doc-utils, libavahi-client-dev (= 0.6.0), libavahi-glib-dev (= 0.6.0), libebook1.2-dev Standards-Version: 3.6.2 Package: ekiga
Bug#382534: mxv: FTBFS due to X.org transition, g++4, and fortran
Package: mxv
Version: 1.32-3
Severity: serious
Tags: patch
Hi,
now that ivtools was updated to provide a correct Imakefile fragment,
mxv fails to compile because:
* it uses old /usr/X11R6/include path
* it needs g++4 tweaks
* it needs a fortran guru
I know that mxv has been requested to be removed (#364092), so maybe
this bug is not worth it.
Using the patch provided in the BTS for #280302 and the patch attached
to this report, compilation goes fine until link, where it mysteriously
fails with:
/usr/lib/libf2c.so: undefined reference to `MAIN__'
collect2: ld returned 1 exit status
From what I have seen, mxv does not really use fortran but only libf2c,
the one complaining. Also, attempting to link with g77 instead of f2c
succeeds (see the second diff) but I don't think that the way to go.
Thomas
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
--- Imakefile- 2006-07-28 21:20:06.347527000 +0200
+++ Imakefile 2006-07-28 21:20:28.852933500 +0200
@@ -164,7 +164,7 @@
XCOMM ARCH_CCDEFINES = -DOSS -DXDisplay=_XDisplay -DCOMPLEX_SUPPORTED
-Div2_6_minmax_h
ARCH_OBJS = MyString.o MyRegex.o error.o
-ARCH_CCINCLUDES = -I../$(LOCALINCLUDE) -I/usr/local/include/g++
-I/usr/X11R6/include/IV-2_6 -I/usr/X11R6/include
+ARCH_CCINCLUDES = -I../$(LOCALINCLUDE) -I/usr/local/include/g++
-I/usr/include/IV-2_6 -I/usr/include
XCOMM On systems which have builtin.h installed, use this next line.
XCOMM ARCH_CCINCLUDES = -I/usr/local/include/g++
--- repclone.C- 2006-07-28 21:28:47.500097000 +0200
+++ repclone.C 2006-07-28 21:30:04.732923750 +0200
@@ -49,7 +49,7 @@
selection.intMin() this-realLength() ?
selection.size() : 0,
chanrange.size()) {
offsetPointer(
- getHandle(selection.intMin(), chanrange.intMin()) -
this-arrayOffset()
+ this-getHandle(selection.intMin(), chanrange.intMin()) -
this-arrayOffset()
);
}
--- debian/rules- 2006-07-28 21:11:14.494288250 +0200
+++ debian/rules2006-07-28 21:11:38.339778500 +0200
@@ -36,7 +36,7 @@
dh_testdir
# Add here commands to compile the package.
- $(MAKE)
+ $(MAKE) CCLINKER=g77
#docbook-to-man debian/mxv.sgml mxv.1
touch build-stamp
--- Imakefile- 2006-07-28 21:20:06.347527000 +0200
+++ Imakefile 2006-07-28 21:20:28.852933500 +0200
@@ -19,7 +19,7 @@
XCOMM most modern Gnu platforms the libf2c library comes with the Gnu C++
XCOMM libraries.
-APP_FORTLIBS = -lf2c
+APP_FORTLIBS =
#if defined(SunArchitecture)
Bug#378525: ivtools 1.1.3-5.3 NMU diff
Hello, Please find the NMU patch for 1.1.3-5.3. Cheers, Thomas diff -u ivtools-1.1.3/config/site.def.DEBIAN ivtools-1.1.3/config/site.def.DEBIAN --- ivtools-1.1.3/config/site.def.DEBIAN +++ ivtools-1.1.3/config/site.def.DEBIAN @@ -49,9 +49,8 @@ MakeDir(dest) @@\ $(INSTALL) -c $(INSTLIBFLAGS) Concat(lib,libname.so.rev) dest @@\ [EMAIL PROTECTED] [ -f dest/Concat(lib,libname.so) ]; then exit 0; else \@@\ - pushd dest; \ @@\ - $(LN) Concat(lib,libname.so.rev) Concat(lib,libname.so.maj);\ @@\ - $(LN) Concat(lib,libname.so.maj) Concat(lib,libname.so); popd; fi + $(LN) Concat(lib,libname.so.rev) dest/Concat(lib,libname.so.maj);\ @@\ + $(LN) Concat(lib,libname.so.maj) dest/Concat(lib,libname.so); fi diff -u ivtools-1.1.3/src/scripts/ivmkmf ivtools-1.1.3/src/scripts/ivmkmf --- ivtools-1.1.3/src/scripts/ivmkmf +++ ivtools-1.1.3/src/scripts/ivmkmf @@ -27,13 +27,13 @@ case $do_all in yes) set -x - imake -T template -I/usr/X11R6/lib/ivtools/config -DCURDIR=\`pwd\` -DUseInstalled + imake -T template -I/usr/lib/ivtools/config -DCURDIR=\`pwd\` -DUseInstalled make Makefile ARCH=LINUX UseInstalled=1 make Makefiles ARCH=LINUX UseInstalled=1 make depend UseInstalled=1 ;; *) set -x - imake -T template -I/usr/X11R6/lib/ivtools/config -DCURDIR=\`pwd\` -DUseInstalled + imake -T template -I/usr/lib/ivtools/config -DCURDIR=\`pwd\` -DUseInstalled make Makefile ARCH=LINUX UseInstalled=1 ;; esac diff -u ivtools-1.1.3/debian/changelog ivtools-1.1.3/debian/changelog --- ivtools-1.1.3/debian/changelog +++ ivtools-1.1.3/debian/changelog @@ -1,3 +1,11 @@ +ivtools (1.1.3-5.3) unstable; urgency=low + + * Non-maintainer upload. + * Remove bashism from config/site.def.DEBIAN (Closes: #372649). + * Remove remaining references to /usr/X11R6 (Closes: #378525, #380123). + + -- Thomas Girard [EMAIL PROTECTED] Sat, 29 Jul 2006 23:09:12 +0200 + ivtools (1.1.3-5.2) unstable; urgency=low * Non-maintainer upload. diff -u ivtools-1.1.3/debian/rules ivtools-1.1.3/debian/rules --- ivtools-1.1.3/debian/rules +++ ivtools-1.1.3/debian/rules @@ -33,8 +33,8 @@ cp -p /usr/share/misc/config.* src/scripts/ ./configure \ - --x-includes=/usr/X11R6/include \ - --x-libraries=/usr/X11R6/lib \ + --x-includes=/usr/include \ + --x-libraries=/usr/lib \ --prefix=`pwd`/debian/tmp/usr \ --mandir=`pwd`/debian/tmp/usr/share/man \ $(ACE) @@ -53,14 +53,14 @@ # build environment # --- - ./configure --x-includes=/usr/X11R6/include \ - --x-libraries=/usr/X11R6/lib \ + ./configure --x-includes=/usr/include \ + --x-libraries=/usr/lib \ --prefix=/usr \ --mandir=`pwd`/debian/tmp/usr/share/man cd src/scripts \ make ARCH=LINUX clean \ - make ARCH=LINUX CONFIGDIRSPEC='-T template -I/usr/X11R6/lib/ivtools/config -DCURDIR=\`pwd\`'\ + make ARCH=LINUX CONFIGDIRSPEC='-T template -I/usr/lib/ivtools/config -DCURDIR=\`pwd\`'\ MAKEMAKESPEC='ARCH=LINUX' touch build-stamp @@ -121,9 +121,9 @@ dh_movefiles -p$(PKGDEVEL) dh_movefiles -N$(PKGDEVEL) # -# remove the directories that are installed into /usr/X11R6/include +# remove the directories that are installed into /usr/include # - -rm -r `pwd`/debian/tmp/usr/X11R6/include + -rm -r `pwd`/debian/tmp/usr/include # # ivtools installs the libACE link, we remove it ... hack # diff -u ivtools-1.1.3/debian/template ivtools-1.1.3/debian/template --- ivtools-1.1.3/debian/template +++ ivtools-1.1.3/debian/template @@ -4,7 +4,7 @@ CPU=LINUX ABSTOP=./ -XCONFIGDIR = /usr/X11R6/lib/X11/config +XCONFIGDIR = /usr/lib/X11/config /* * Define the OS platform and CPU architecture. only in patch2: unchanged: --- ivtools-1.1.3.orig/src/ivxt/Imakefile +++ ivtools-1.1.3/src/ivxt/Imakefile @@ -9,7 +9,7 @@ # CCLDFLAGS = CCLdFlags -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/ComUnidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/ComUnidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/UniIdraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/UniIdraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/OverlayUnidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/OverlayUnidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/IV/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/IV/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/Unidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/Unidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/lesstif/lib -L$(PROJECTDIR)/lesstif/lib -L$(PROJECTDIR)/clippoly -CCLDFLAGS = -Wl,-rpath,$(PROJECTDIR)/lesstif/lib -L$(PROJECTDIR)/lesstif/lib -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src
Bug#378525: ivtools: broken -dev package prevents mxv compilation
retitle 378525 ivtools: broken -dev package prevents mxv compilation tags 378525 + patch thanks Hello, the following changes are needed to generate a ivtools-dev package that can be used. With this updated ivtools-dev and the fix for #280302 mxv almost compiles. Thomas diff -Nru --exclude='*~' ivtools-1.1.3-/debian/rules ivtools-1.1.3/debian/rules --- ivtools-1.1.3-/debian/rules 2006-07-27 21:37:11.0 +0200 +++ ivtools-1.1.3/debian/rules 2006-07-27 21:43:28.216874750 +0200 @@ -33,8 +33,8 @@ cp -p /usr/share/misc/config.* src/scripts/ ./configure \ - --x-includes=/usr/X11R6/include \ - --x-libraries=/usr/X11R6/lib \ + --x-includes=/usr/include \ + --x-libraries=/usr/lib \ --prefix=`pwd`/debian/tmp/usr \ --mandir=`pwd`/debian/tmp/usr/share/man \ $(ACE) @@ -53,14 +53,14 @@ # build environment # --- - ./configure --x-includes=/usr/X11R6/include \ - --x-libraries=/usr/X11R6/lib \ + ./configure --x-includes=/usr/include \ + --x-libraries=/usr/lib \ --prefix=/usr \ --mandir=`pwd`/debian/tmp/usr/share/man cd src/scripts \ make ARCH=LINUX clean \ - make ARCH=LINUX CONFIGDIRSPEC='-T template -I/usr/X11R6/lib/ivtools/config -DCURDIR=\`pwd\`'\ + make ARCH=LINUX CONFIGDIRSPEC='-T template -I/usr/lib/ivtools/config -DCURDIR=\`pwd\`'\ MAKEMAKESPEC='ARCH=LINUX' touch build-stamp @@ -121,9 +121,9 @@ dh_movefiles -p$(PKGDEVEL) dh_movefiles -N$(PKGDEVEL) # -# remove the directories that are installed into /usr/X11R6/include +# remove the directories that are installed into /usr/include # - -rm -r `pwd`/debian/tmp/usr/X11R6/include + -rm -r `pwd`/debian/tmp/usr/include # # ivtools installs the libACE link, we remove it ... hack # diff -Nru --exclude='*~' ivtools-1.1.3-/debian/template ivtools-1.1.3/debian/template --- ivtools-1.1.3-/debian/template 2006-07-27 21:37:11.0 +0200 +++ ivtools-1.1.3/debian/template 2006-07-27 21:39:56.855665500 +0200 @@ -4,7 +4,7 @@ CPU=LINUX ABSTOP=./ -XCONFIGDIR = /usr/X11R6/lib/X11/config +XCONFIGDIR = /usr/lib/X11/config /* * Define the OS platform and CPU architecture. diff -Nru --exclude='*~' ivtools-1.1.3-/src/ivxt/Imakefile ivtools-1.1.3/src/ivxt/Imakefile --- ivtools-1.1.3-/src/ivxt/Imakefile 2003-10-22 20:15:53.0 +0200 +++ ivtools-1.1.3/src/ivxt/Imakefile2006-07-27 21:45:20.611899000 +0200 @@ -9,7 +9,7 @@ # CCLDFLAGS = CCLdFlags -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/ComUnidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/ComUnidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/UniIdraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/UniIdraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/OverlayUnidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/OverlayUnidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/IV/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/IV/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/Unidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/Unidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/lesstif/lib -L$(PROJECTDIR)/lesstif/lib -L$(PROJECTDIR)/clippoly -CCLDFLAGS = -Wl,-rpath,$(PROJECTDIR)/lesstif/lib -L$(PROJECTDIR)/lesstif/lib -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/ComUnidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/ComUnidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/GraphUnidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/GraphUnidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/OverlayUnidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/OverlayUnidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/ComGlyph/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/ComGlyph/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/ComTerp/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/ComTerp/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/AttrGlyph/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/AttrGlyph/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/Attribute/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/Attribute/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/ComUtil/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/ComUtil/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/UniIdraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/UniIdraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/IVGlyph/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/IVGlyph/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/TopoFace/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/TopoFace/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/Unidraw/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/Unidraw/$(CPU) -Wl,-rpath,$(PROJECTDIR)/ivtools-0.6/src/IV/$(CPU) -L$(PROJECTDIR)/ivtools-0.6/src/IV/$(CPU) -L/usr/X11R6/lib -L$(PROJECTDIR)/clippoly -L$(PROJECTDIR)/ACE_wrappers/ace +CCLDFLAGS = -Wl,-rpath,$(PROJECTDIR)/lesstif/lib -L$(PROJECTDIR)/lesstif/lib
Bug#378605: please depend on xerces27 instead of xerces26
I apologize for not having posted this bug earlier with a lower severity, but I overlooked the ace package as a reverse dependency on xerces26 because none of the binary packages have runtime dependencies on libxerces26c2. This makes me wonder whether the build dependency on libxerces26-dev may be superfluous. You may want to double check that before updating the dependency. Once ace is no longer dependent upon libxerces26-dev, the xerces26 removal request can be completed. Thanks! Hum... I'll check today but I guess you're right. It is probably used to compile something that is no longer packaged. I'll fix this, thanks ! Indeed, it was once needed to compile DAnCE. But DAnCE is not packaged and today it is no longer compiled. I've commited a fix in r377 [1], thanks for noticing. Thomas [1] http://svn.debian.org/wsvn/pkg-ace
