Bug#737261: ITP: nghttp2 -- HTTP/2 library
Package: wnpp Severity: wishlist Owner: Dave Beckett daj...@debian.org Package name: nghttp2 Version : 0.2.0 Upstream Author : Tatsuhiro Tsujikawa t-tujik...@users.sourceforge.net URL : http://tatsuhiro-t.github.io/nghttp2/ License : MIT/X Programming Lang: C Description : HTTP/2 library A library that provides an experimental implementation of Hypertext Transfer Protocol version 2.0 including a server (nghttpd), client (nghttp) and reverse proxy (nghttpx) for fronting other HTTP servers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658829: db5.3 transition to db6.0 - license has changed
Starting with the 6.0 / 12c releases, all Berkeley DB products are licensed under the GNU AFFERO GENERAL PUBLIC LICENSE (AGPL), version 3. -- http://docs.oracle.com/cd/E17076_03/html/installation/license_change60.html This probably means that some things cannot link with db6.0 and so will have to stick with db5 Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656928: libraptor2-0: please add a Breaks against libraptor1 versions without symbol versioning
That option was removed from raptor's configure some time ago, it just generates a warning and has no new effect since libxml2 is now the only choice. Dave On Mon, 10 Sep 2012, Jonathan Nieder wrote: Dave Beckett wrote: There are no more changes coming for 2.0.8 I didn't realise it was blocked so go ahead Ok, neat. Quick question: --- raptor2-2.0.8/debian/rules 2012-06-24 23:31:55.0 -0700 +++ raptor2-2.0.8/debian/rules 2012-09-07 21:54:14.0 -0700 @@ -13,7 +13,6 @@ DEB_DBG_PACKAGE_libraptor2-0 = libraptor2-0-dbg DEB_CONFIGURE_USER_FLAGS= \ - --with-xml-parser=libxml \ --enable-release What's this about? It doesn't seem to be mentioned in debian/changelog. Puzzled, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656928: libraptor2-0: please add a Breaks against libraptor1 versions without symbol versioning
On 9/8/12 1:58 PM, Jonathan Nieder wrote: Dave Beckett wrote: * debian/control: add a breaks relation by libraptor2-0 against squeeze libraptor1 to force upgrades to a version with symbol versioning (Closes: #656928) * Added debian/patches/001-remove-m-strict-help.patch to remove -m strict from rapper help (Closes: #685682) Thanks! If you'd like, I can take care of asking the release team to include these changes in wheezy. Would that be useful, or are there more changes coming soon? (Of course, if someone else wants to file the unblock request instead, all the better.) There are no more changes coming for 2.0.8 I didn't realise it was blocked so go ahead Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685682: rapper -m strict
This is a documentation bug. -m strict was removed from rapper as part of the Raptor V2 work. It's replacement is -f strict=true (default is -f strict=false) I will update the help message Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676169: more info needed
I read the description but I don't think I can attempt to reproduce or diagnose this. I need steps like: install this package, type this Thanks Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625523: cairomm new version
There's a version 1.10.0 out now (9 May 2011). I intend to package that instead of the 1.9.x series. Can you check if that is ok for gtkmm3.0 Thanks Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613672: libraptor2-0: Please build with versioned symbols
You'll get good enough symbol versions by adding LDFLAGS += -Wl,--default-symver I can try this but I'm skeptical it will fix the essential problem - two versions of the same library in the same memory space. It's not just symbols, it's that they will attempt to use and control the same resources. In this case as an examples they are libxml (which does a terrible job of managing static resources and the libraries will fight over who owns the error management global variables) and curl (which is fine). The main point is that slv2 needs to be ported to raptor2. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561681: crashes on startup
On 2/15/11 7:12 AM, Frederic Peters wrote:
Dave Beckett wrote:
An aside at Ardour:
If I look in sid at ardour, it says:
Build-Depend:
... libraptor1 (= 1.4.19), librasqal2 (= 0.9.18), librdf0 (= 1.0.9),
which is shortly going to break since the latest librdf0 will shortly
require librasqal3 and libraptor2. If ardour really uses raptor V1 API/ABI,
it'll need porting. If it uses librdf API/ABI, it just needs a rebuild.
And here we are, this morning after my system got librdf0 1.0.13-1
Ardour failed as you announced:
Core was generated by `/usr/lib/ardour2/ardour-2.8.11'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f884c6b6b95 in librdf_parser_raptor_constructor () from
/usr/lib/librdf.so.0
(gdb) bt full
#0 0x7f884c6b6b95 in librdf_parser_raptor_constructor () from
/usr/lib/librdf.so.0
No symbol table info available.
#1 0x7f884c6a9fd5 in librdf_world_open () from /usr/lib/librdf.so.0
No symbol table info available.
#2 0x7f884bfd3a27 in slv2_world_new () from /usr/lib/libslv2.so.9
No symbol table info available.
#3 0x7f88542ef179 in ARDOUR::LV2World::LV2World (this=0x7fffcf93f830) at
libs/ardour/lv2_plugin.cc:561
No locals.
#4 0x7f885423daad in ARDOUR::PluginManager::PluginManager
(this=0x1163040)
at libs/ardour/plugin_manager.cc:127
s = value optimized out
lrdf_path = {static npos = 18446744073709551615,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x7f883c000a08 /usr/local/share/ladspa/rdf:/usr/share/ladspa/rdf}}
#5 0x7f88541ed15e in ARDOUR::init (use_vst=value optimized out,
try_optimization=value optimized out)
at libs/ardour/globals.cc:358
p = 0x0
vamppath = {static npos = 18446744073709551615,
_M_dataplus = {std::allocatorchar =
{__gnu_cxx::new_allocatorchar = {No data fields}, No data fields},
_M_p = 0x1162658 /usr/lib/ardour2/vamp}}
node = value optimized out
#6 0x005333e7 in ARDOUR_UI::ARDOUR_UI (this=0xe908c0, argcp=value
optimized out,
argvp=value optimized out, __in_chrg=value optimized out,
__vtt_parm=value optimized out)
at gtk2_ardour/ardour_ui.cc:250
No locals.
#7 0x0074d27a in main (argc=1, argv=0x7fffcf940a28) at
gtk2_ardour/main.cc:392
No locals.
(gdb)
I dont know the exact reason here but I'm guessing that if Ardour links to
both librdf0 and libraptor1, it'll now (librdf0 1.0.13+) bring in libraptor2
with different but overlapping set of symbols. At that point, a crash is likely.
Dave
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613411: More info
On 2/15/11 7:21 AM, Adrian Knoth wrote:
Hi!
I've built a debug version of librdf and found the following code:
librdf_parser_raptor_constructor (world=0x877e5a0) at
rdf_parser_raptor.c:1328
1328syntax_name = desc-names[0];
(gdb) bt
#0 librdf_parser_raptor_constructor (world=0x877e5a0)
at rdf_parser_raptor.c:1328
#1 0xb65b27bd in librdf_init_parser (world=0x877e5a0) at rdf_parser.c:55
#2 0xb65a3ca5 in librdf_world_open (world=0x877e5a0) at rdf_init.c:303
#3 0xb64e739c in slv2_world_new () from /usr/lib/libslv2.so.9
#4 0xb7f6b3a9 in ARDOUR::LV2World::LV2World() ()
from /usr/lib/ardour2/libardour.so
#5 0xb7eaefd4 in ARDOUR::PluginManager::PluginManager() ()
from /usr/lib/ardour2/libardour.so
#6 0xb7e5a184 in ARDOUR::init(bool, bool) ()
from /usr/lib/ardour2/libardour.so
#7 0x08165255 in ARDOUR_UI::ARDOUR_UI(int*, char***) ()
#8 0x08392e5b in main ()
(gdb) frame 0
#0 librdf_parser_raptor_constructor (world=0x877e5a0)
at rdf_parser_raptor.c:1328
1328syntax_name = desc-names[0];
(gdb) list
1323if(!desc) {
1324 /* reached the end of the parsers, now register the
default one */
1325 i = 0;
1326 desc =
raptor_world_get_parser_description(world-raptor_world_ptr, i);
1327}
1328syntax_name = desc-names[0];
1329syntax_label = desc-label;
1330if(desc-mime_types)
1331 mime_type = desc-mime_types[0].mime_type;
1332if(desc-uri_strings)
(gdb) p desc
$1 = (const raptor_syntax_description *) 0x0
This code has been added after librdf0-1.0.10 for librdf-1.0.11.
Obviously, description is NULL, and dereferencing it causes the
segfault.
I wonder if raptor_world_get_parser_description should have returned
something different. I cannot judge if it's something big or if a simple
NULL pointer check in librdf_parser_raptor_constructor would be enough,
maybe also using the old code from 1.0.10 in case of desc==NULL.
The desc should never be NULL since it's running through a list from raptor,
and the final one is to get the default parser. The only way this can
happen is if raptor wasn't initialised properly, which is my guess here. I
suspect ardour is linking to raptor1 and raptor2, and thus crashing.
Dajobe, I guess we could use your input here. ;)
JFTR, this is the initialization code in libslv2:
SLV2World
slv2_world_new()
{
SLV2World world = (SLV2World)malloc(sizeof(struct _SLV2World));
world-world = librdf_new_world();
if (!world-world) {
free(world);
return NULL;
}
world-local_world = true;
librdf_world_open(world-world);
return slv2_world_new_internal(world);
}
Cheers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561681: crashes on startup
On 1/21/10 2:26 AM, Benjamin Scherrer wrote: Hi, this bug seems to be still active to me. I'm up to date on Debian testing amd64 with the versions: ardour 2.8.4-3 librdf0 1.0.10-1 librdf0-dev 1.0.10-1 librasqal2 0.9.17-1 librasqal2-dev 0.9.17-1 But I still get this console output: $ /usr/bin/ardour2 /usr/lib/ardour2/ardour-2.8.4: error while loading shared libraries: librasqal.so.1: cannot open shared object file: No such file or directory Even if I build Ardour from source, I get: $ /usr/local/bin/ardour2 /usr/local/lib64/ardour2/ardour-2.8.4: error while loading shared libraries: librasqal.so.1: cannot open shared object file: No such file or directory librasqal.so.1 has not been packaged for some years librasqal.so.2 was introduced in rasqal 0.9.17-1 of 16 Dec 2009 and is the one in stable. (librasqal.so.3 just arrived in 0.9.24-1 of 31 Jan 2011 and is in sid but not testing yet) So the ardour2 binary you have there has broken dependencies or was compiled against the wrong library or something else. An aside at Ardour: If I look in sid at ardour, it says: Build-Depend: ... libraptor1 (= 1.4.19), librasqal2 (= 0.9.18), librdf0 (= 1.0.9), which is shortly going to break since the latest librdf0 will shortly require librasqal3 and libraptor2. If ardour really uses raptor V1 API/ABI, it'll need porting. If it uses librdf API/ABI, it just needs a rebuild. It's surprising it requires both dependencies; does it really uses those symbols? Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561681: crashes on startup
On 1/21/10 3:51 AM, Benjamin Scherrer wrote: Hi, I also asked at the Ardour forums about this problem. (http://ardour.org/node/3287) As advices there, a quick ln -s /usr/lib/librasqal.so.2 /usr/lib/librasqal.so.1 as root solved my problems. That seems indicates ardour must have been compiled against a different rasqal ABI to it's declared depencies. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613050: Sorry about this
This clearly shouldn't have been uploaded until raptor2 was accepted into sid (1 month waiting), which is a dependency. I built it against my own local copy. Not sure how to resolve it now. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558137: More updated 4store package
I applied Kjetil's patch and made some other changes to give 1.0.3-2 at http://download.dajobe.org/debian/unstable/ 4store (1.0.3-2) unstable; urgency=low . * debian/control: Build-Depend: on libavahi-client-dev and libavahi-glib-dev to get mDNS enabled * set initial KB to 'default' * really run server as user 'fourstore' * do not run server at package install time * install a skeleton /etc/default/4store Getting closer to what I'd submit, but I'd like a co-maintainer. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558137: Willing to sponsor 4store packages
The links here don't seem recent and working but if there are some packages in a reasonable state, I'll take a look. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558137: test debian package of 4store
I made a test package of 4store 1.0.3 (latest release) at http://download.dajobe.org/debian/unstable/ Based on a much derived version of some earlier work. It builds and is relatively lintian clean but I haven't tested it. It makes a new user 'fourstore' but I've just remembered it still starts it as root instead of setuid with start-stop-daemon. Nevermind - that'll have to be in another attempt. The server doesn't start at package install since there are no DB files created, but otherwise the init scripts are built. So if you want to run it as root, install this and then sudo /etc/init.d/4store start Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575638: glitz: not maintained and probably should be removed
On Fri, 7 May 2010, Jari Aalto wrote: In that case, would you like to file the removal request to ftp masters or is it okay if I do it? Thanks for keeping Debian archives in shape, Jari Go ahead and file it Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575638: Glitz is not maintained and probably should be removed
See subject Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579261: cairo 1.8.4 has been packaged for some weeks - wait for that to reach debian testing
At the time of your email 1.8.4 had been packaged and installed for 6 days. The 1.8.4-2 has a critical fix and it's uploading now. 10 days after that reaches unstable, it'll migrate to testing and this bug will become out of date and I'll close it. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560298: Please package cython 0.12
One more vote for a new version - some software I want to use needs this. Thanks Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566292: php5-librdf: missing dependency on phpapi-*
Your package builds a PHP extension but doesn't depend on phpapi-*. This is incorrect and will break it on PHP transitions, such as the soon-to-come PHP 5.3 transition. Why is it incorrect and where was this announced and documented? You should have filed a wishlist or lower priority bug well in advance of rushing to do a 1-day NMU. It's not clear what you propose to change (so therefore I cannot do it myself) but if it is just debian/rules and debian/control, go ahead with the NMU. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561681: crashes on startup
Adrian Knoth wrote: On Sat, Dec 19, 2009 at 05:02:21PM +0100, hungerburg wrote: Hi! the last time I used ardour two days ago. I believe it was 1:2.8.4-1 - today after updating to 1:2.8.4-2 I can no longer launch the application. A downgrade does not help. Maybe its because a file changed that ardour uses but that is in another package. We have to sort things out. I claim that it's not an ardour bug, ardour's working fine over here and you say that downgrading doesn't fix the bug, so it's very likely not ardour's fault. I'll reassign the bug to the appropriate package once we know the culprit. Below valgrind output shows an invalid memory access while loading lv2 plugins. I am not aware that debian ships any of those though or that such plugins are installed on this system here. We do have LV2 plugins in Debian, however, ardour's LV2 code is rather stable. See below. ==29391== Jump to the invalid address stated on the next line ==29391==at 0xC: ??? ==29391==by 0x58CEF8F: rasqal_engine_execute_init (in /usr/lib/librasqal.so.1.0.0) ==29391==by 0x58CA128: rasqal_query_execute (in /usr/lib/librasqal.so.1.0.0) ==29391==by 0x58A8781: ??? (in /usr/lib/librdf.so.0.0.0) ==29391==by 0x58A5D49: librdf_query_execute (in /usr/lib/librdf.so.0.0.0) ==29391==by 0x595A83D: slv2_world_load_specifications (in /usr/lib/libslv2.so.9.2.0) ==29391==by 0x595AE93: slv2_world_load_all (in /usr/lib/libslv2.so.9.2.0) ==29391==by 0x424E262: ARDOUR::LV2World::LV2World() (in /usr/lib/ardour2/libardour.so) ==29391==by 0x4198453: ARDOUR::PluginManager::PluginManager() (in /usr/lib/ardour2/libardour.so) ==29391==by 0x41462D0: ARDOUR::init(bool, bool) (in /usr/lib/ardour2/libardour.so) ==29391==by 0x816080C: ARDOUR_UI::ARDOUR_UI(int*, char***) (in /usr/lib/ardour2/ardour-2.8.4) ==29391== Address 0xc is not stack'd, malloc'd or (recently) free'd Here we go. As always, stack traces are bottom up. We see that ardour calls some LV2 functions which are handled by libslv2. This library does the whole LV2 discovery stuff. Further up the stack trace, we see librdf executing a query, which is then passed to librasqal. Both libs, librdf and librasqal, have new versions in unstable since yesterday, so I guess one of them is the culprit: http://packages.qa.debian.org/r/redland.html http://packages.qa.debian.org/r/rasqal.html (new versions on 2009-12-17) When I downgrade librdf0 to 1.0.9-3, ardour starts fine. That's why I would say librdf0 is the real culprit here. I'm now building ardour against new librdf0 to see if this fixes the issue, but I don't think so. (libs are expected to be backward compatible, that is, ardour built against librdf0-1.0.9 should run with librdf0-1.0.10. However, I'll CC the librdf0 maintainer, so he has the chance to do some investigations himself. From the stack trace I can see a problem - the librdf is calling the old rasqal ABI (0.9.16) in librasqal.so.1 rather than the new (0.9.17) in librasqal.so.2. (Assuming these are redland librdf 1.0.10 and rasqal librdf 0.9.17) redland 1.0.10 (librdf.so.0) was packaged to link with the new rasqal 0.9.17 (librasqal.so.2) and so the above stack trace should not be possible, unless I've got the shared lib/package dependencies wrong. Maybe librasqal2 should conflict with librasqal1. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559826: analysis of vulnerable redland versions
No version before 1.0.9 is vulnerable - they do not use libtool and ltdl. That leaves: testing/squeeze 1.0.9-2 unstable/sid1.0.9-3 which are vulnerable. No etch or lenny releases are vulnerable. redland 1.0.9 upstream was built with libtool 2.2.6 so patching source file redland-1.0.9/libltdl/ltdl.c with the one from the 2.2.6b release should fix it. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559372: compiling against flickcurl
The package is not as you put useless. Yes, the libxml2-dev dependency needs adding but otherwise, it's still 1 line to compile a program against flickcurl: gcc -o prog prog.c `pkg-config flickcurl --cflags` `pkg-config flickcurl --libs` and that *does* include the right include line. flickcurl-config does need fixing too. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523043: brasero: Segmentation fault while loading libgstladspa.so
reassign 523043 liblrdf forcemerge 521898 523043 done fixing previous reassignment - liblrdf != librdf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511841: Redland 1.0.9 with dynamic loading / repackaged storage backends
FYI the next release of redland 1.0.9 has the dynamic loading storages enabled so that means the packages can be adjusted to have just a core with the simple storages (sqlite, bdb, files) separate from packages for the relational backends (mysql, postgresql, others in future). I'm just noting this info to the bugs in question so I can start to think about how to rearrange the packages and guess at names: librdf0 librdf_storage_mysql ? librdf-storage-mysql ? containing the single file: /usr/lib/redland/librdf_storage_mysql.so ( I don't think it needs the .la) same questions for postgresql Should I add a librdf-storage-all package that pulls everything in? suggestions welcome I might as well add a debug package while I'm doing it too Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523686: redland cflags
If you are compiling against redland correctly you have two choices to set up the compile flags correctly either a) $ redland-config --cflags -I/usr/include/rasqal (which uses the program /usr/bin/redland-config in librdf0-dev) or b) $ pkg-config redland --cflags -I/usr/include/rasqal (which uses /usr/lib/pkgconfig/redland.pc in librdf0-dev) Both of which will set up the include path correctly. BTW a) is deprecated but supported. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519695: raptor links against openssl, makes a lot of packages undistributable
Michael Biebl wrote: Hi Dave, could you please comment on this issue and if you'd be willing to compile libraptor against libcurl-gnutls. Sure, it's only used to get https urls working. I don't care which library implements that. I haven't tested it but assume it works. Dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495620: any chance of fix making it to release?
Mark Hedges wrote: The latest libcairo2_1.6.4-6.1 did not contain this fix. I had to downgrade using your packages. Any chance your patch to libcairo2_1.6.4-6.0.1 can make it into the next upgrade? I don't now where this fix that was in Mike's build called libcairo2_1.6.4-6.0.1 came from. It's not in the #495620 comments and I don't have the source to this build either. So those are reasons enough for not including it; apart from not wanting to make a new release of cairo which is in freeze and part of the dep-chain of many packages. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499662: Proposed changes for #499662
The patch looks OK although I cannot test any directfb stuff, or do any cairo work today. One reason the directfb was NOT enabled in the main cairo package by me is that it is unsupported upstream. The customer for debian is really just the installer, so limiting the packages for that was a goal, and also to make the udeb minimal size. Any reported bugs on directfb outside the installer are unlikely to get any resolution from me or upstream. So the larger issue is the release-affecting consequences of this change. Please can somebody confirm that's it's approved by release team BEFORE any packaging is done. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497838: cairo_draw_with_xlib
Mike Hommey said: Looks like it's happening in cairo. #6 0xb7241e2d in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:216 #7 signal handler called #8 cairo_draw_with_xlib (cr=0xbc55ff8, callback=0xb79c4698 NativeRendering, closure=0xbfea8c40, dpy=0x0, width=560, height=228, is_opaque=CAIRO_XLIB_DRAWING_OPAQUE, capabilities=27, result=0x0) at cairo-xlib-utils.c:329 #9 0xb79c4789 in gfxXlibNativeRenderer::Draw (this=0xbfea8c94, dpy=0x0, ctx=0xbc47e40, width=560, height=228, flags=0, output=0x0) at gfxXlibNativeRenderer.cpp:101 #10 0xb73e5131 in nsPluginInstanceOwner::Paint (this=0x9ed4290, [EMAIL PROTECTED], [EMAIL PROTECTED]) at nsObjectFrame.cpp:4076 cairo_draw_with_xlib() is part of mozilla's codebase (firefox, mozilla, xulrunner whatever) not cairo and as far as I can find, there is no cairo_draw_with_xlib() at line 329 of cairo-xlib-utils.c at least as far as http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/src/cairo-xlib-utils.c is concerned - whatever tree I choose. Where the matching source is, I can't say. Isn't it suspicious these are being called with a NULL X Display in dpy? Seems to be a firefox/mozilla/xulrunner bug to me. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477331: More information about this issue
Otavio Salvador wrote: notfound 1.4.14-1 found 1.5.6-1 thanks I've been able to reproduce the issue outside d-i environment, using cdebconf, and this allowed me to test with previous available versions of package. I figure that, of available packages, the first to show this issue is 1.5.6-1 while 1.4.14-1 was the last one to be working. Thanks for the info. If you could tell me how to invoke cdebconf with gtk+directfb cairo, that would help me look at the cairo side. I was trying to avoid having to do d-i environment work. Did you try 1.5.4 and it was OK? It was in experimental. So far we know: 1.4.14: good 1.5.2: ? (2007-10-30) (this wasn't packaged in debian) 1.5.4: ? (2007-12-05) 1.5.6: bad (2008-01-15) At present I have a suspicious commit that might be the cause: http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=ad0a2524ffdc9cc949d11de3aa51c429f13e12b7 made 2008-01-02 which is currently in the right period. So if 1.5.4 works, it might be that. It's still at http://snapshot.debian.net/archive/2008/01/17/debian/pool/main/c/cairo/ Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477064: RFA: nant -- .NET build tool similar to Ant
Package: wnpp Severity: normal I request an adopter for the nant package as I no longer use or have interest in .NET/mono. The package description is: NAnt is different. Instead of a model where it is extended with shell-based commands, NAnt is extended using task classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface. There are two serious bugs on nant: 1) #475213: nant: FTBFS: [csc] /build/user/nant-0.85/src/NAnt.DotNet/Tasks/ScriptTask.cs(519,50): error CS0612: `System.Reflection.Assembly.LoadWithPartialName(string)' is obsolete http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475213 This isn't important I feel, since once built by the maintainer, nant never needs rebuilding. 2) #374634: nant: includes binary-only copies of nunit, SharpZipLib and log4net in source tarball (DFSG §2 violation) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374634 Requires a tedious and complex dive into nant's wierd build system. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466336: O: ikvm -- Java virtual machine/compiler implemented in .NET (Mono)
Package: wnpp Severity: normal I intend to orphan the ikvm package. To any future maintainer: There are lots of packaging problems that ikvm 0.36.0.5 have including needing extra source packages, plus licensing concerns of combining OpenJDK, Classpath and IKVM code, some of which is only available in unreleased software. A complete pain I'd imagine. ikvm is a b*gger to build and regularly fails when the mono toolchain changes (which is often). It also fails to build on many architectures. Good luck. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463344: build against libcurl4-gnutls
... libcurl4-openssl-dev, which conflicts with several other packages... I can imagine both versions clash with other packages. Can you provide some more specific details to pick one over the other? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457914: RM: libpixman -- RoM; obsolete
Package: ftp.debian.org Severity: normal Please remove the following packages from unstable (all architectures): libpixman1 - Cairo pixel manipulation library libpixman1-dev - Cairo pixel manipulation library development libraries and headers which are generated from the libpixman source package They have been superceded by new source package pixman with it's binary packages libpixman-1-0 libpixman-1-dev and libpixman-1-0-dbg already in unstable. Thanks Dave -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-k7 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385026: Debian cairo bug 385026 may be fixed, please check
The cairo upstream bug for this: http://bugzilla.gnome.org/show_bug.cgi?id=359243 claims it was fixed in cairo 1.2+ series which was a long time ago. Attilio: can you check since you knew of the workaround? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413690: this is cairo bug 9719
This is cairo bug https://bugs.freedesktop.org/show_bug.cgi?id=9719 Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454768: liferea: crashes with SIGFPE
Nico Golde wrote: Hi Gabor, * Gabor Gombas [EMAIL PROTECTED] [2007-12-11 15:02]: On Tue, Dec 11, 2007 at 02:46:59PM +0100, Nico Golde wrote: I did not forget it, it was attached by the one who replied to this bug before me :) Hmm, that mail did not reach me for some reason. Anyways, I've extracted the patch from the BTS and I can confirm that if fixes the problem on i386. Will check amd64 in the evening. Thank you. I again contacted the upstream author because I definetely miss the insight about the libcairo code base to see what is causing this. Dave, are you available to do the next upload? The best would be to upload the new upstream version. I've packaged 1.4.12 but it's in the NEW queue, ETA 1 week by the look of it. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436065: ITP: flickcurl -- C library for the Flickr API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kumar Appaiah wrote: Package: wnpp Severity: wishlist Owner: Kumar Appaiah [EMAIL PROTECTED] * Package name: flickcurl Version : 0.11 Upstream Author : Dave Beckett [EMAIL PROTECTED] * URL : http://librdf.org/flickcurl/ * License : LGPL 2.1 / GPL 2 /Apache 2.0 Programming Lang: C Description : C library for the Flickr API Flickcurl is a C library for the Flickr API, handling creating the requests, signing, token management, calling the API, marshalling request parameters and decoding responses. It uses libcurl to call the REST web service and libxml2 to manipulate the XML responses. The current version supports part of the API, primarily the functions for reading photo, people and tags description, uploading photos, changing tags and comments. Hello, as you can see I'm the author, and I'm also a Debain Developer. I was looking at the thread on debian-mentors about this http://www.mail-archive.com/[EMAIL PROTECTED]/msg51084.html With respect to example.c - that should be in the public domain, I've made it so in SVN. My only other comment on the packaging is that very likely the FTP masters would reject it because there are two packages with only a couple of files: flickcurl, flickrdf and their man pages. In a real package layout I expect a flickcurl-utils package that contained both would be more acceptible to them, although you can never tell. Dave -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGti5WQ+ySUE9xlVoRAnXaAJ9M4Uk983MXDNHDXCHunnbTCyryiACeMWhR BqjhfXBeRTd9PC5OS4Dtc0A= =krUG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431465: ITP: libsvg -- library for parsing SVG files
Rene Engelhard wrote: Package: wnpp Severity: wishlist Owner: Rene Engelhard [EMAIL PROTECTED] * Package name: libsvg Version : 0.1.4 Upstream Author : Carl Worth [EMAIL PROTECTED] * URL : http://cairographics.org/snapshots/ * License : LGPL Programming Lang: C Description : library for parsing SVG files libsvg provides a parser for SVG content in files or buffers. The last upstream release was in 2005, though and it's still only under snapshots/, so it seems quite dead upstream. OOo will in the future most probably use it for svg import, though... (http://svn.gnome.org/viewcvs/ooo-build/trunk/patches/src680/svg-import.diff?revision=9660view=markup) If anyone else than me wants to maintain this (Dave?), be welcome to take this ITP :-) libsvg is dead upstream and not supported, not under development. I talked to Carl today and he was surprised OOo was using it. librsvg is something that is supported, maybe you can get them to use that.. Otherwise, you become the maintainer of libsvg :) Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429672: libcairo: shlibs file are broken regarding udeb
Jérémy Bobbio wrote: Package: libcairo Version: 1.4.6-1.1 Severity: important Hi! libcairo2 and libcairo-directfb2 .shlibs files disagree on which dependencies should be used for udebs: * /var/lib/dpkg/info/libcairo2.shlibs libcairo 2 libcairo2 (=1.4.0) udeb: libcairo 2 libcairo-directfb2-udeb (=1.4.0) * /var/lib/dpkg/info/libcairo-directfb2.shlibs libcairo 2 libcairo2 (=1.4.0) udeb: libcairo 2 libcairo2 (=1.4.0) The former looks good, but the later package (which is a dependency of libgtk-directfb-2.0-dev) results in udebs linked against cairo getting a wrong Depends on libcairo2. Loïc Minier have suggested that no libcairo2 should have no udeb entries and that libcairo-directfb2 should only gets the udeb entry. That sentence has a double negative, could you rephrase to say more clearly what you are suggesting? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425331: librdf0-dev: Please update to db4.4
Michael Biebl wrote: Package: librdf0-dev Severity: normal Currently librdf builds and links against libdb4.3, librfd0-dev depends on libdb4.3-dev. Unfortunately, most of the other packages, like libsvn were built against db4.4, and the -dev packages of libsvn can't be installed in paralle with librd0-dev, because libdb4.3-dev and libdb4.4-dev conflict with each other. redland 1.0.6 in experimental (due to the months of freezing) is linked against db4.4 and depends on libdb4.4-dev. I can rebuilt it for sid. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422388: [Pkg-gtk2-perl-maintainers] Bug#422388: libcairo-perl: FTBFS: t/CairoSurface....dubious
Marc 'HE' Brockschmidt wrote: tags 422388 + fixed-upstream thanks Heya, Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: Lucas Nussbaum [EMAIL PROTECTED] writes: During a rebuild of all packages in sid, I discovered that your package failed to build on i386. After some investigation, I tracked this problem down to an issue in libcairo. See my report to upstream [1], upstream's reaction [2] and upstream's mail to the cairo list reporting the same bug [3] and including a reduced test-case (and a patch for a part of the issue). The errors causing this problem have now been fixed [1]. Please upload a package including these bugfixes soon, as this bug is breaking other packages. Marc Footnotes: [1] http://lists.freedesktop.org/archives/cairo/2007-May/010636.html Please NMU libcairo with this fix only if you want it before next Wed or Thu, I'm not able to properly package and test it before then. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421878: libcairomm-1.0-dev: Newer upstream versions available
Guus Sliepen wrote: Package: libcairomm-1.0-dev Version: 0.6.0-4 Severity: important Hello, upstream has released cairomm 1.2.4 on January 17, 2007. Please update the Debian package. I set the severity to important, because the latest version of gtkmm also depends on cairomm = 1.2.0. If you want I can help package cairomm 1.2.4. It's been packaged and sitting in experimental. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421266: libcairo2: libcairo 1.4.4 breaks Azureus
Dirk Haage wrote:
Dave Beckett wrote:
On Fri, 27 Apr 2007, Dirk Haage wrote:
Package: libcairo2
Version: 1.4.4-1
Severity: important
when version 1.4.4-1 of libcairo2 is installed, Azureus is not able
to start:
Error: Cairo 1.4.4 does not yet support the requested image format:
Depth: 32
Alpha mask: 0x
Red mask: 0xffe0
Green mask: 0x001ffc00
Blue mask: 0x03ff
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
java:
/home/dajobe/dev/debian/cairo/libcairo-1.4.4/src/cairo-image-surface.c:199:
_cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.
../azureus: line 112: 23177 Aborted
${JAVA_PROGRAM_DIR}java -Xms16m -Xmx128m -cp ${CLASSPATH}
-Djava.library.path=${PROGRAM_DIR}
-Dazureus.install.path=${PROGRAM_DIR} org.gudy.azureus2.ui.swt.Main
$@
Azureus TERMINATED.
Did you follow the instructions in the error message above?
Please give me the cairo bug number when you do, and I can
make this bug depend on it.
There is already a similar bug reported for version 1.4.2:
https://bugs.freedesktop.org/show_bug.cgi?id=10513
Not similar at all since all the image format parameters are
different.
So that would be a 'No' - you didn't follow the instructions?
Dave
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421266: libcairo2: libcairo 1.4.4 breaks Azureus
On Fri, 27 Apr 2007, Dirk Haage wrote:
Package: libcairo2
Version: 1.4.4-1
Severity: important
when version 1.4.4-1 of libcairo2 is installed, Azureus is not able to start:
Error: Cairo 1.4.4 does not yet support the requested image format:
Depth: 32
Alpha mask: 0x
Red mask: 0xffe0
Green mask: 0x001ffc00
Blue mask: 0x03ff
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
java:
/home/dajobe/dev/debian/cairo/libcairo-1.4.4/src/cairo-image-surface.c:199:
_cairo_format_from_pixman_format: Assertion `NOT_REACHED' failed.
../azureus: line 112: 23177 Aborted ${JAVA_PROGRAM_DIR}java -Xms16m -Xmx128m -cp
${CLASSPATH} -Djava.library.path=${PROGRAM_DIR}
-Dazureus.install.path=${PROGRAM_DIR} org.gudy.azureus2.ui.swt.Main $@
Azureus TERMINATED.
Did you follow the instructions in the error message above?
Please give me the cairo bug number when you do, and I can
make this bug depend on it.
Dave
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393691: Is this bug (ikvm FTBFS on amd64) still relevant?
Brian M. Carlson wrote: Is this bug still relevant? ikvm has successfully built on amd64 since this bug was filed, and it works on my amd64 machine. ISTR that some bug was present in Mono a few months ago, and that might have affected the build environment. I've never had it working, and the state of the debian test machines for this kind of thing is pathetic. I can test come Monday or Tuesday (probably the latter) that ikvm still builds on amd64, if needed. Let me know. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411144: libcairo2 broken
On Fri, 16 Feb 2007, Jerome Blondel wrote: Package: libcairo2 Version: 1.2.4-4 # LANG=en apt-get -s install libcairo2 Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: libcairo2: Depends: libfontconfig1 (= 2.4.0) but 2.3.1-2 is to be installed Depends: libfreetype6 (= 2.2) but 2.1.7-6 is to be installed E: Broken packages You are mixing up unstable and stable packages. libfreetype6 2.1.7-6 is in stable libcairo2 is NOT in stable in any version libcairo 1.2.4-4 is in unstable/testing and depends on the versions in unstable/testing Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400552: tomboy: crashes on start
Shawn K. Quinn wrote: Package: tomboy Version: 0.4.1-2 Severity: grave Justification: renders package unusable After recent upgrades, tomboy crashes on start: ... It worked for me when I built it. Why don't you try 0.5.0 in experimental at http://ftp.debian.org/debian/pool/main/t/tomboy/ and see if that fixes it for you. I'm suspicious about D-Bus which has a newer version (1.0.1-2) than 0.4.1 was built with (0.9.3) and continues to prove it is not something you can rely on. tomboy 0.5.0 was built with the latest dbus at 14 Nov (1.0.0) Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399195: python-cairo: python2.3 import fail
Loic Dachary wrote: Thanks for the explanation. I'm confused though because apt-cache show claims support for python2.3. Any idea why this is so ? When I built it, there might have been support for python2.3. Although I haven't changed anything, the python defaults have changed, so there is no longer any support for 2.3 - basically, at the point of installation, the python defaults get applied by 'pycentral' so it's out of my hand. I've just compiled a new version of pycairo in experimental and all mention of 2.3 is now removed from the build. This was caused by the build-time use of the python defaults noticing the change. Confusing? Yes. But this is the route the python people took. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397703: python-librdf: import RDF fails
Jeroen Pulles wrote: Package: python-librdf Version: 1.0.4.1-2 Severity: normal Hi Dave, import RDF fails because RDF.py is not in the modules path. RDF.py is available in the pycentral/python-librdf/site-packages directory. I can't find any (byte-compiled) copies or symlinks in the python site-packages directories, though. Is something missing in the install script, or am I supposed to run pycentral manually? It should be in the search path, pycentral makes the symlink and installs it for each python version: $ python2.4 Python 2.4.4 (#2, Oct 20 2006, 00:23:25) [GCC 4.1.2 20061015 (prerelease) (Debian 4.1.1-16.1)] on linux2 Type help, copyright, credits or license for more information. import RDF RDF.__file__ '/usr/lib/python2.4/site-packages/RDF.pyc' $ ls -l /usr/lib/python2.4/site-packages/RDF.py* lrwxrwxrwx 1 root root 55 Oct 3 23:19 /usr/lib/python2.4/site-packages/RDF.py - /usr/share/pycentral/python-librdf/site-packages/RDF.py -rw-r--r-- 1 root root 74561 Oct 3 23:19 /usr/lib/python2.4/site-packages/RDF.pyc -rw-r--r-- 1 root root 74527 Apr 23 2006 /usr/lib/python2.4/site-packages/RDF.pyo Maybe you should re-install the package? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396345: tomboy: Tomboy does not start
Andrey Fedoseev wrote: Package: tomboy Version: 0.4.1-2 Severity: grave Justification: renders package unusable ... When trying to run tomboy I get: [START] ** ERROR **: file threadpool.c: line 990 (mono_thread_pool_init): assertion failed: (async_call_klass) aborting... = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Stacktrace: Native stacktrace: /usr/lib/libmono.so.0 [0xa7df0dd2] /usr/lib/libmono.so.0 [0xa7dc46ec] [0xe440] /lib/tls/i686/cmov/libc.so.6(abort+0x109) [0xa7b7dfb9] /usr/lib/libglib-2.0.so.0(g_logv+0x454) [0xa7d10114] /usr/lib/libglib-2.0.so.0(g_log+0x29) [0xa7d10149] /usr/lib/libglib-2.0.so.0(g_assert_warning+0x77) [0xa7d101c7] /usr/lib/libmono.so.0 [0xa7e8dd62] /usr/lib/libmono.so.0(mono_runtime_init+0x23) [0xa7e95505] /usr/lib/libmono.so.0 [0xa7dc5b74] /usr/lib/libmono.so.0(mono_main+0x1388) [0xa7de1fe5] mono [0x8048522] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc8) [0xa7b68ea8] mono [0x8048471] Debug info from gdb: (no debugging symbols found) Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1481300288 (LWP 18461)] [New Thread -1484702800 (LWP 18462)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0xe410 in __kernel_vsyscall () 2 Thread -1484702800 (LWP 18462) 0xe410 in __kernel_vsyscall () 1 Thread -1481300288 (LWP 18461) 0xe410 in __kernel_vsyscall () Thread 2 (Thread -1484702800 (LWP 18462)): #0 0xe410 in __kernel_vsyscall () #1 0xa7cbf016 in __nanosleep_nocancel () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xa7ec8b4b in mono_type_full_name () from /usr/lib/libmono.so.0 #3 0xa7cb9240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xa7c1f27e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread -1481300288 (LWP 18461)): #0 0xe410 in __kernel_vsyscall () #1 0xa7be19a9 in fork () from /lib/tls/i686/cmov/libc.so.6 #2 0xa7cc05b4 in fork () from /lib/tls/i686/cmov/libpthread.so.0 #3 0xa7d320c9 in g_spawn_error_quark () from /usr/lib/libglib-2.0.so.0 #4 0xa7d32c9f in g_spawn_sync () from /usr/lib/libglib-2.0.so.0 #5 0xa7d33115 in g_spawn_command_line_sync () from /usr/lib/libglib-2.0.so.0 #6 0xa7df0e9a in mono_debugger_run_finally () from /usr/lib/libmono.so.0 #7 0xa7dc46ec in mono_jit_thread_attach () from /usr/lib/libmono.so.0 #8 signal handler called #9 0xe410 in __kernel_vsyscall () #10 0xa7b7c821 in raise () from /lib/tls/i686/cmov/libc.so.6 #11 0xa7b7dfb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #12 0xa7d10114 in g_logv () from /usr/lib/libglib-2.0.so.0 #13 0xa7d10149 in g_log () from /usr/lib/libglib-2.0.so.0 #14 0xa7d101c7 in g_assert_warning () from /usr/lib/libglib-2.0.so.0 #15 0xa7e8dd62 in mono_thread_stop () from /usr/lib/libmono.so.0 #16 0xa7e95505 in mono_runtime_init () from /usr/lib/libmono.so.0 #17 0xa7dc5b74 in mono_jit_thread_attach () from /usr/lib/libmono.so.0 #18 0xa7de1fe5 in mono_main () from /usr/lib/libmono.so.0 #19 0x08048522 in ?? () #20 0x0002 in ?? () #21 0xafeb23f4 in ?? () #22 0xafeb2378 in ?? () #23 0x0804854f in ?? () #24 0xa7b5ec8c in ?? () from /lib/tls/i686/cmov/libc.so.6 #25 0xafeb2380 in ?? () #26 0xafeb23c8 in ?? () #27 0xa7b68ea8 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #28 0xa7b68ea8 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #29 0x08048471 in ?? () #0 0xe410 in __kernel_vsyscall () Aborted [END] I had tomboy (v0.3xxx) running fine before I updated some packages (I don't remember exactly which packages were updated) a couple days ago. After that I updated tomboy to 0.4.1-2 and it didn't help. ... Versions of packages tomboy depends on: ii libmono-corlib1.0-cil 1.1.13.8-1Mono core library (1.0) ii libmono-system1.0-cil 1.1.13.8-1Mono System libraries (1.0) ii libmono1.0-cil 1.1.17.1-5Mono libraries (1.0) ii mono-runtime 1.1.13.8-1Mono runtime You seem to be using at least 2 different versions of the core Mono libraries which means your system is inconsistent. Maybe you could try using the
Bug#396414: tomboy: crashes on start: assertion failed: (async_call_klass) in threadpool.c:990
On Tue, 31 Oct 2006, jetxee wrote: Package: tomboy Version: 0.4.1-1 Severity: normal After upgrade from 0.3.3-3 to 0.4.1-1 tomboy does not start any more. It seems like a broken dependency on mono, but all dependencies are satisfied. The stderr output of the programme follows: ... Versions of packages tomboy depends on: ii libmono-corlib1.0-cil 1.1.13.8-1Mono core library (1.0) ii libmono-system1.0-cil 1.1.13.8-1Mono System libraries (1.0) ii libmono1.0-cil 1.1.17.1-5Mono libraries (1.0) ii mono-runtime 1.1.13.8-1Mono runtime Try using a single version of the mono packages rather than 2. I suggest 1.1.18 which is the latest. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389303:
Jesse Alec Wolfe wrote: This bug affects my system, too. It still occurs in the most recent unstable (0.8.5-1.1). I spoke to the developers in #muine, and they tell me that this issue is fixed in CVS. (until then, Muine is nearly unusable: can we get a pre-release package in experimental? having to use XMMS is really unpleasant) I'd rather just apply the patch that fixes it than package an unreleased version for this bug. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383034: Some diagnosis
Nigel: you say:
I connect to my Debian system from OS X (latest) using 'ssh -Y'. Using
gdb xsane, I get: [crash]
when I do the same from OSX, it works just fine but does nothing
since I don't have a scanner.
I probably can't test things like:
dimensions:3120x1050 pixels (1055x355 millimeters)
in your configuration. That's an expensive monitor.
There is a possibility this might be caused by
https://bugs.freedesktop.org/show_bug.cgi?id=7953
which has a fix in git (attached).
Dave
--- cairo-1.2.4.orig/src/cairo-xlib-surface.c 2006-08-18 07:20:16.0 -0700
+++ cairo-1.2.4/src/cairo-xlib-surface.c 2006-09-23 16:06:26.0 -0700
@@ -2450,7 +2449,7 @@
}
n = new;
d = data;
- while ((c -= 4) = 0)
+ while (c = 4)
{
n[3] = d[0];
n[2] = d[1];
@@ -2458,6 +2457,7 @@
n[0] = d[3];
d += 4;
n += 4;
+ c -= 4;
}
data = new;
}
Bug#388116: More info needed
Looking at the end of the backtrace: Core was generated by `pan'. Program terminated with signal 11, Segmentation fault. #0 0xb79281f9 in cairo_xlib_surface_get_display () from /usr/lib/libcairo.so.2 #1 0xb790d7b1 in cairo_surface_reference () from /usr/lib/libcairo.so.2 #2 0xb7901fdc in cairo_font_options_create () from /usr/lib/libcairo.so.2 #3 0xb78fc844 in cairo_show_glyphs () from /usr/lib/libcairo.so.2 In Cairo 1.2.4 and earlier (I looked back to 1.0.0) there is no code path between cairo_show_glyphs() calling cairo_font_options_create() or between cairo_surface_reference() calling cairo_xlib_surface_get_display() so there must be some other corruption problem happening. There is a small chance this is the same thing as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383034 which has something that looks like an upstream fix in https://bugs.freedesktop.org/show_bug.cgi?id=7953 if we believe the problem is in #3 cairo_show_glyphs() and think anything above that is bogus. Otherwise, I'll need a backtrace against cairo compiled with debugging on. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386110: GNOME app's fail to start
Toufeeq Hussain wrote: Subject: libcairo2: GNOME app's fail to start Package: libcairo2 Version: 1.2.4-1 Severity: critical Justification: breaks unrelated software *** Please type your report below this line *** All GNOME app's fail to start. They quit with the following error: symbol lookup error: /usr/lib/libgdk-x11-2.0.so.0: undefined symbol: cairo_xlib_surface_create This is something wrong with your system. The shipped debian cairo package contains that symbol. $ grep cairo_xlib_surface_create /usr/lib/libcairo.so.2 Binary file /usr/lib/libcairo.so.2 matches and if you have libcairo2-dev installed: $ nm /usr/lib/libcairo.a|grep cairo_xlib_surface_create 3540 t _cairo_xlib_surface_create_internal 3aa0 t _cairo_xlib_surface_create_similar 3890 t _cairo_xlib_surface_create_similar_with_format 3c30 T cairo_xlib_surface_create 3be0 T cairo_xlib_surface_create_for_bitmap 3840 T cairo_xlib_surface_create_with_xrender_format Problem seems to be with pango/cairo and can be fixed by rolling back to earlier version. Found a similar problem with the Fedora folk as can be seen here. http://www.redhat.com/archives/fedora-devel-list/2006-August/msg00289.html That bug is irrelevant. I was the person who found that problem when I packaged cairo 1.2.4 and reported it upstream. It was never in any debian cairo package. The first google hit for a problem is not useful information. It is most likely you have your own compiled version of cairo installed. Delete that and your applications will work. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383034: GTK apps crashing in /usr/lib/libcairo.so.2 cairo_xlib_surface_get_display()
Nigel Johnston wrote: I've just been trying to run various GTK based apps and they all fail in the same place - cairo_xlib_surface_get_display(), so I guess I've got the same problem. I connect to my Debian system from OS X (latest) using 'ssh -Y'. Using gdb xsane, I get: So it's not a debian X server. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1487959840 (LWP 24660)] 0xa79441f9 in cairo_xlib_surface_get_display () from /usr/lib/libcairo.so.2 Gimp gives: Program received signal SIGSEGV, Segmentation fault. 0xa7a7a1f9 in cairo_xlib_surface_get_display () from /usr/lib/libcairo.so.2 Firefox also crashes. What does xdpyinfo show? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383034: libcairo2: every gtk app crashes when runs on remote
Marcelo Monteiro wrote: I was idem problem. I use vncserver and gtk application crash with 1.2.2. When I downgrade to 1.0.4 everything works fine. Please can you give more information on your X setup. What does xdpyinfo show? Also note there are bugs with 8-bit displays not fixed upstream which might be what you are hitting. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383034: libcairo2: every gtk app crashes when runs on remote Xsession
Emil Nowak wrote: Package: libcairo2 Version: 1.2.2-1 Severity: normal I'm using ssh X11Forwarding to run applications remotely from other machines. As long as I remember it worked well. But with the current libairo every gtk application crashes on startup on cairo_xlib_surface_get_display(). When I downgrade to 1.2.0 everything works fine. I can't duplicate this, nobody else seems to have reported it, which suggests it is something local to you. Complete gdb backtrace attached. that wasn't really helpful as it is some gtk application you wrote. Starting program: /home/emil/programing/C/gtk/fc ... Can you demonstrate this crashing with a standard debian gtk application? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383297: Please --enable-pdf and --enable-ps in the DirectFB flavor
Loïc Minier wrote: tag 383297 + patch stop Hi, On Wed, Aug 16, 2006, Loïc Minier wrote: I've rebuilt libcairo (with a newer directfb snapshot too, see #383238) with these flags, and Gtk 2.10 now links fine. I've confirmed this also works with unstable's DirectFB. I attach the patch of the NMU I prepared to get local packages. Please let me know if I may upload it. No. The cairo directfb packages are for making a udeb only and I'm not going to increase their size. More when I've time to reply to your long email. Dave
Bug#381665: libcairo and libfreetype versions
Please report this information as soon as possible. The very same thing has been reported previous times and it was always a local configuration problem with out of date freetype. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325526 for what I mean and tests you can try. I will downgrade or close this bug if I do not hear anything in a couple of days. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376714: Summary of the status of the libcairo upstream #7494 bugs
Adeodato Simó wrote: unmerge 377147 retitle 377147 libcairo 1.2.0: regression: gtk apps are not anti-aliased if anti-aliasing is disabled in ~/.qt/qtrc notforwarded 377147 unblock 377879 by 377147 unblock 379482 by 377147 retitle 376714 libcairo 1.2.0 text disappears after first word if anti-aliasing disabled retitle 378005 libcairo 1.2.0 text disappears after first word if anti-aliasing disabled severity 376714 serious tags 376714 fixed-upstream patch thanks All this reminds me why I hate the debian bug system. wtf was all that? Hi. There are currently three merged bugs open against libcairo, all of them forwarded to upstream #7494: #376714: Cairo 1.2.0 fonts disappear after first word #377147: firefox: text rendering badly damaged #378005: libcairo2 problem with non-anti-aliased text As can be read in upsream #7494, only the disappearing text in non-antialiasing mode is being considered there, so I am unmerging #377147, and will follow-up to it separately. I've also rebuilt libcairo2 applying the patch provided by upstream [1], and I confirm it solves the disappearing text problem. Since I really think that bug makes the package unreleasable, I've raised its severity to serious. HTH, [1] http://gitweb.freedesktop.org/?p=cairo;a=commitdiff;h=456cdb3058f3b416109a9600167cd8842300ae14;hp=8601c2c68306c956744399099a941363d446b906 Thanks for testing the patch that was created while I was sleep 7 hours ago. I can't really have been expected to do that myself :) I'll consider applying it, but I'll see if a new upstream release is imminent. I am tracking the upstream bugs closely. Dave
Bug#377147: anti-aliasing with cairo+gtk+firefox on kde
The antialiasing problem seems to be caused by the KDE bug mentioned in the cairo bug https://bugs.freedesktop.org/show_bug.cgi?id=7494 [[ I think I've figured out what was all this about, and it's not cairo's fault. In fact, it's been a fix on cairo (http://gitweb.freedesktop.org/?p=cairo;a=commit;h=fe324c44153cf37a51b51883780daee5500173be, TTBOMK) what has exposed bugs in other layers. For example, if I set Xft.antialiasing to 0, with cairo 1.0.4 I still get antialiased apps, but not with cairo 1.2.0. This explain the behavior observed in comment 2, but it's still a bug on KDE (hopefully I can point to an URL later). ]] -- Adeodato Simó The KDE fix mentioned is http://websvn.kde.org/branches/KDE/3.5/kdebase/kcontrol/krdb/krdb.cpp?rev=551202r1=541552r2=551202 If this is confirmed fixes it, I think this bug should be reassigned to kdebase. Dave
Bug#325526: libcairo2: undefined symbol 'FT_GlyphSlot_Embolden'
Oliver Jato wrote:
hello,
the file seems to be okay:
...
flyricky:/home/olli# cat foo.c
main() { FT_GlyphSlot_Embolden(); }
flyricky:/home/olli# less foo.c
flyricky:/home/olli# gcc -o foo foo.c -lcairo
flyricky:/home/olli# ./foo
flyricky:/home/olli#
so in terms of this bug, it works for you.
after adding /usr/local/lib again to ld.so.conf, ldconfig -v showed me
libpng12.so.0 in /usr/local/lib and /usr/lib. is this the right
behaviour?
Your own compile of major app libs like libpng12 probably the cause of all
sorts of problems. See the gcc failure to link; it somehow burnt in a path
to a different library.
The rest of the crashes I think are your problem.
it probably doesn't help because svg files still don't work with a
removed /usr/local/lib, but this is the listing of it:
...
-rw-r--r-- 1 root staff 2378932 2005-03-08 23:32 libfreetype.a
-rwxr-xr-x 1 root staff 822 2005-03-08 23:32 libfreetype.la
lrwxrwxrwx 1 root staff 20 2005-03-08 23:32 libfreetype.so -
libfreetype.so.6.3.7
lrwxrwxrwx 1 root staff 20 2005-03-08 23:32 libfreetype.so.6 -
libfreetype.so.6.3.7
-rwxr-xr-x 1 root staff 1470054 2005-03-08 23:32 libfreetype.so.6.3.7
Your 15-month old version of freetype here is the cause of your crash - the
library had some bugs and the real debian version fixes them, and also
includes the function that is not found. The debian cairo package depends
on the debian version of freetype that has the function.
I really suggest you delete everything from /usr/local/lib that already
exists in /usr/lib. It will cause you to see problems that do not exist
with debian-maintained libraries.
As far as this bug is concerned, I'm taking no action - it's all due to
configuration on your system.
Dave
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325526: libcairo2: undefined symbol 'FT_GlyphSlot_Embolden'
Oliver Jato wrote:
Package: libcairo2
Version: 1.2.0-3
Severity: important
Distribution: unstable
System: Linux flyricky 2.6.17-1-k7 #1 SMP Mon Jul 17 13:21:38 UTC 2006
i686 GNU/Linux
libc6: 2.3.6-15
Package: libcairo2
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 676
Maintainer: Dave Beckett [EMAIL PROTECTED]
Architecture: i386
Source: libcairo
Version: 1.2.0-3
Replaces: libcairo0.5.1, libcairo0.6.0, libcairo0.9.0, libcairo1
Provides: libcairo
Depends: libc6 (= 2.3.6-6), libfontconfig1 (= 2.3.0), libfreetype6 (=
2.2), libice6, libpng12-0 (= 1.2.8rel), libsm6, libx11-6, libxrender1,
zlib1g (= 1:1.2.1)
Conflicts: libcairo1
Description: The Cairo 2D vector graphics library
similar/same problem here. effect is that svg files cannot be opened and
applications die at startup, probably because they use svg.
i stumbled across this error message when libwmf0.2-7 was upgraded:
Updating the gdk-pixbuf loaders list for GTK+-2.4.0...g_module_open()
failed
for /usr/lib/gtk-2.0/2.4.0/loaders/svg_loader.so: /usr/lib/libcairo.so.2:
undefined symbol: FT_GlyphSlot_Embolden
Please check that you really have don't have it.
The correct file for 1.2.0-3 on i386 is:
$ md5sum /usr/lib/libcairo.so.2
52efee151b4d1f730c83e32dc2f092ec /usr/lib/libcairo.so.2
$ strings /usr/lib/libcairo.so.2 | grep FT_GlyphSlot_Embolden
FT_GlyphSlot_Embolden
so it's definitely there in the correct file.
$ cat foo.c
main() { FT_GlyphSlot_Embolden(); }
$ gcc -o foo foo.c -lcairo
$ ./foo
as an example for an application crash, this is how amarok dies since
the upgrade:
amarok: /usr/local/lib/libpng12.so.0: no version information available
(required by /usr/lib/libqt-mt.so.3)
Amarok: [Loader] Starting amarokapp..
Amarok: [Loader] Don't run gdb, valgrind, etc. against this binary! Use
amarokapp.
/usr/lib/amarok/amarokapp: /usr/local/lib/libpng12.so.0: no version
information available (required by /usr/lib/libqt-mt.so.3)
this is a local libpng you are running, not the standard one. This suggests
you might have /usr/local/lib in your library search path and have other
local libraries there that are affecting things.
Amarok: [Loader] amarokapp probably crashed!
Dave
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377347: libcairomm-1.0-dev: can't use PDF, PS or SVG
Nick Lewycky wrote: Package: libcairomm-1.0-dev Version: 0.6.0-2 Severity: normal The examples for PsSurface, PdfSurface and SvgSurface don't link: $ g++ `pkg-config --cflags --libs cairomm-1.0` cairograph.cpp /tmp/ccqYR7Sy.o: In function `main': cairograph.cpp:(.text+0x141): undefined reference to `Cairo::SvgSurface::create(std::basic_stringchar, std::char_traitschar, std::allocatorchar , double, double)' collect2: ld returned 1 exit status $ g++ `pkg-config --cflags --libs cairomm-1.0` /usr/share/doc/libcairomm-1.0-dev/examples/svg-surface/main.cc -o main /tmp/ccZcxUsu.o: In function `main': main.cc:(.text+0x124): undefined reference to `Cairo::SvgSurface::create(std::basic_stringchar, std::char_traitschar, std::allocatorchar , double, double)' collect2: ld returned 1 exit status $ g++ `pkg-config --cflags --libs cairomm-1.0` /usr/share/doc/libcairomm-1.0-dev/examples/ps-surface/main.cc -o main /tmp/ccLi5Woc.o: In function `main': main.cc:(.text+0x124): undefined reference to `Cairo::PsSurface::create(std::basic_stringchar, std::char_traitschar, std::allocatorchar , double, double)' collect2: ld returned 1 exit status $ g++ `pkg-config --cflags --libs cairomm-1.0` /usr/share/doc/libcairomm-1.0-dev/examples/pdf-surface/main.cc -o main /tmp/ccxdZmCy.o: In function `main': main.cc:(.text+0x132): undefined reference to `Cairo::PdfSurface::create(std::basic_stringchar, std::char_traitschar, std::allocatorchar , double, double)' collect2: ld returned 1 exit status $ g++ `pkg-config --cflags --libs cairomm-1.0` /usr/share/doc/libcairomm-1.0-dev/examples/png_file/main.cc -o main $ ./main Wrote png file image.png $ eog image.png Yep, ImageSurface works fine. Perhaps they aren't linked in? Also, the examples are protected by #ifdef's that are supposed to compile-time detect whether these surfaces are enabled in Cairo (not in cairomm). They aren't being triggered. They were not supported in older cairos (1.2.0) so were not enabled in the C library. Newer cairo supports them, but the cairomm 0.6.0 has not yet been updated/been rebuilt to reflect this. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373860: cairo bug
This seems more like a compiler problem, the mathcalls.h lines are things like: extern double y1 (double) __attribute__ ((__nothrow__)); extern double __y1 (double) __attribute__ ((__nothrow__)); (after pre-processor expansion) The name in a function declaration. In cairo, they are parameters in different function declarations. In C, these are not shadowed declarations since function declaration parameters have the scope of the function declaration only. I suggest this bug applies to whatever compiler you are using; you don't mention a version. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325526: libcairo2: undefined symbol 'FT_GlyphSlot_Embolden'
ASJ wrote: Package: libcairo2 Version: 1.2.0-3 Followup-For: Bug #325526 In the latest update to 1.2.0-3 anything using python's wxGtk interface dies on startup: Traceback (most recent call last): File CastPodderGui.py, line 32, in ? import wx File /usr/lib/python2.3/site-packages/wx-2.6-gtk2-unicode/wx/__init__.py, line 42, in ? from wx._core import * File /usr/lib/python2.3/site-packages/wx-2.6-gtk2-unicode/wx/_core.py, line 4, in ? import _core_ ImportError: /usr/lib/libcairo.so.2: undefined symbol: FT_GlyphSlot_Embolden Can't duplicate, and I'm using the same libraries and arch as you. $ sudo apt-get install python-wxgtk2.6 ... $ python Python 2.3.5 (#2, Jun 13 2006, 23:12:55) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-4)] on linux2 Type help, copyright, credits or license for more information. import wx Recompling and rebuilding the libcairo deb fixed the problem. which means there's no comparison with your system now. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377259: Insufficient dependencies for libcairo.la causes FTBFS
Loïc Minier wrote: Package: libcairo2-dev Version: 1.2.0-2 Severity: serious Hi, #377234 was just filed against gnome-keyring which uses libtool and pkg-config --libs gtk+-2.0 to build. libtool sees the -lcairo from this command and includes the dependency_libs of libcairo.la which includes -lSM. libcairo2-dev should hence depend on libsm-dev. It also uses -lICE which isn't in the dependencies either and seems to be made by the configure AC_PATH_XTRA macro. I can't look that up to find out why on debian since the project has removed all autoconf documentation. Since libsm-dev depends on libice-dev, adding the former should be sufficient. (If you want to remove libcairo.la altogether, be aware that it is referenced in other *.la files and needs coordination with our release team as it will either require removal of *.la files in -dev packages depending on libcairo2-dev or rebuild of these packages.) I'm not removing any .la files unless it becomes something coordinated and managed by the release team for all packages that use libtool. Dave
Bug#365387: libglitz1: please update to version 0.5.3
Nick Lewycky wrote: Package: libglitz1 Version: 0.4.4-1 Severity: wishlist The latest release snapshot of glitz is version 0.5.3, which is one of the components needed to compile Xgl. The debian/ directory from 0.4.4 can be inserted into the 0.5.3 directory tree just fine. Please update. I remember looking into it last week, and the same problem remains as then, that Xorg 7.0.0 has messed up everything. At present glitz's configure fails to find the X11 headers and it's correct X11/Intrinsic.h has gone, or at least it's hiding in one of the thousand Xorg packages there are now, but it's not under something obvious. ... checking for Win32... no checking for X... no checking for AGL.framework... no checking for WGL... no ... Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347675: ping - does libcairo2 segv nautilus
You said re cairo 1.0.2-3 on 12 Jan 2006: So, maybe just downgrade this bug report to severity normal and I'll re-check with the next regular unstable version. If you haven't seen this crash since then, I'd propose to close this bug as unreproducable. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362964: don't start tomboy with --debug
Benoît Dejean wrote: Package: tomboy Version: 0.3.3-3 Severity: normal Please change /usr/bin/tomboy so that tomboy's mono VM is not started with --debug. This saves some memory. Thanks. It doesn't start with debug in normal use: $ sh -x /usr/bin/tomboy + '[' -e ./Tomboy.exe ']' + export LD_LIBRARY_PATH=/usr/lib/tomboy: + LD_LIBRARY_PATH=/usr/lib/tomboy: + export TOMBOY_WRAPPER_PATH=/usr/bin/tomboy + TOMBOY_WRAPPER_PATH=/usr/bin/tomboy + THIS_EXE=/usr/lib/tomboy/Tomboy.exe + '[' -n /usr ']' + export MONO_GAC_PREFIX=/usr: + MONO_GAC_PREFIX=/usr: + exec mono /usr/lib/tomboy/Tomboy.exe ... although I think that script is over-engineered and should be replaced by something a lot shorter, such as: #!/bin/sh export LD_LIBRARY_PATH=/usr/lib/tomboy:$LD_LIBRARY_PATH export MONO_GAC_PREFIX=$MONO_GAC_PREFIX:/usr exec /usr/bin/cli /usr/lib/tomboy/Tomboy.exe $@ Dave
Bug#362243: pycairo: please add svg support
Sebastian Rittau wrote: Package: pycairo Severity: wishlist It would be great the Debian package of pycairo could support SVG. Currently libsvg and libsvg-cairo aren't packaged, but I would be willing to work on that if pycairo will then get SVG support. Neither (cairo) libsvg or libsvg-cairo are stable and supported. Only packages under http://cairographics.org/releases/ are supported. Both are snapshots http://cairographics.org/snapshots/ and I've packaged them under debian for some time: http://cairographics.org/packages/debian/unstable/ If they get put into debian then the maintainer becomes responsible for all their support, and will get no upstream support. I wouldn't make pycairo (stable, supported) depend on an unsupported library. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362237: libcairo2-dev: please recompile against X11R7
Sebastian Rittau wrote: Package: libcairo2-dev Version: 1.0.4-1 Severity: important Please rebuild cairo against X11R7. With X11R7 the .la files have gone from X -dev packages, but are still referenced in /usr/lib/libcairo.la. Why have they been removed? (This would be the right moment to remove the .la file from libcairo2-dev as well.) Not without an explanation. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351894: librasqual provided by package does not work with python bindings
[EMAIL PROTECTED] wrote: Package: librdf0 Version: 1.0.2-2 The librasqual provided by the package, as also reported in librdf's BTS [1], makes Python bindings unusable. [EMAIL PROTECTED]:~/rdf/foaf_db$ python raptor_foaf.py Querying.. rdf_query_rasqal.c:177:rasqal_literal_to_redland_node: Could not convert literal type 2 to librdf_node Aborted The problem goes away when a brand new librasqual.so.0.0.0 is used, while the roqet application works with both libraries This might be fixed for you with one of the librdf 1.0.3 packages but since there was no test program attached to the bug, I can't tell. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358230: Please place headers in a proper place
On Wed, 2006-03-22 at 14:52 +0100, Bernhard R. Link wrote: * Dave Beckett [EMAIL PROTECTED] [060322 08:11]: ... I am not going to do either of these. The choice cairo made is perfectly acceptable and good, common practice. I even want to challenge the common practise part. Even the related libraries glib, atk, gdk, gtk do not place things this way, but have the -I madness only to differentiate between different versions, any version-less directory names are properly placed in the #include directives. That's all convention, there are no (debian in this case) standards for requiring what you ask for. I am not convinced by any of your argument. You should use pkg-config and not try to second-guess what compile/link options it generates. pkg-config is a way to work around things like uncabable toolsets or broken libraries. I acknowledge that it should be used for some things. But I'm talking here about Linux and not something like Windows. There are enough ways to create libraries in a way that no compile/link options are needed at all. Using a tool to reduce the problems with broken libraries is no excuse to generate broken libraries. Well, you go ahead and try to convince all of gnome and beyond do that but you should make sure you have read everything about libtool and pkgconfig when you try. As far as the debian packaged version of cairo is concerned, there is no bug and I will be closing this shortly. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358230: Please place headers in a proper place
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernhard R. Link wrote: libcairo2-dev has headers in /usr/include/cairo that are referenced by itself and by other packages without the cairo subdirectory thus forcing all programs directly or indirectly (e.g. gtk) libcairo to include an -I/usr/include/cairo option. This results in: * long, unreadable compiler command lines (which could grow to long for some limited shells, and causes some people to hide the compiler command line from the user, which again make it unnecesarrily difficult to debug build problems.) compiler command lines can already be very long - try compiling X or kde or gnome. I don't believe anything you write here is a significant problem. * breaking programs not using pkgconfig pkg-config is required for developing with cairo, as it is for a lot of other things. pkg-config is required to compile *with* cairo, as it is used by dependent packages too. Please consider to either (best persuading upstream, otherwise in the Debian package only) to: 1) Move all header files to the place the compiler would look for them. (i.e. /usr/include) 2) Make the compiler look at the proper place, by changing all #include to cairo/..., telling all users of those file to include them that way and removing the -I from cairo.pc to catch all missign places. I am not going to do either of these. The choice cairo made is perfectly acceptable and good, common practice. In either case, there should finaly be no -I in the .pc file. (Unless installed by a user in his home directory, or things like that) There are some cases when a -I option might be necessary, like when upstream forgot to include the version in the names of the headers when making an incompatible change and a Debian package needs to allow installing thus conflicting versions. libcairo does not have any such excuse as far as I can see, as there is only one cairo.h around. I am not convinced by any of your argument. You should use pkg-config and not try to second-guess what compile/link options it generates. Dave -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEIPTDQ+ySUE9xlVoRAkcRAJ948BTPxZH4x4pX0K9ZEcX0HISJrwCfSoox wBsyiFtJHTpVi7ofz2TigMI= =qlZa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353568: Patch for NMU of redland
Luk Claes wrote: Hi Attached the patch for the version I uploaded. Please respond if you think that the attached patch won't work. It will work. This fix is in the redland 1.0.3 build which has been stuck in the new queue for 7 days+ now and closes this bug. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354854: muine: Crashes with libdbus-1-cil_0.61
Javier Kohen wrote: Package: muine Version: 0.8.4-1 Severity: serious Justification: It allows itself to be installed with an incompatible library I just upgraded to dbus-0.61, ... I think you've found the problem. ii libdbus-1-cil0.61-2 CLI binding for D-BUS interprocess According to Bug#354798 dbus 0.61-3 fixes a similar bug report for tomboy and f-spot. Please can you upgrade and try it. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354766: rdf_log.h should include raptor.h
Regis Boudin wrote: Package: librdf0-dev Version: 1.0.2-2 Severity: grave Hi, Trying to build Amaya using the system librdf fails because the raptor_locator type is not defined in rdf_log.h To fix this, I suppose rdf_log.h should include raptor.h You should never include rdf_log.h directly, always #include redland.h which pulls in raptor.h there. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352729: ITP: cairomm -- C++ wrappers for Cairo
Dave Beckett wrote: Are you actually using cairomm under Debian? If not, then you can't really maintain it there. To keep the bug info up-to-date. Danilo doesn't use Debian so can't really maintain it properly. I propose to use his packaging and maintain it myself especially as gtkmm 2.10 will need it. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352729: ITP: cairomm -- C++ wrappers for Cairo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Danilo Piazzalunga wrote: On Tuesday 21 February 2006 04:40, Dave Beckett wrote: If you want this in Debian and can do the packaging, I might be able to sponsor it for you. I'm not really a C++ developer so I would mostly be only checking it on the packaging side of things. I have prepared a package and sumitted to Ubuntu developers for reviewing. It is already available at http://revu.tauware.de/details.py?upid=1898 If you like you can review the package from there (nothing is Ubuntu-specific, except the version number), but if you prefer I can upload it to mentors.debian.net. The packaging looks good. I'm happy to upload it in the current state. I just added a line to close the ITP bug, and to add myself as Uploader: - the rest would be the same. Oh, and did I thank you for your kind offer of sponsorhip? :-) Are you actually using cairomm under Debian? If not, then you can't really maintain it there. Dave -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD+97CQ+ySUE9xlVoRAr15AJ9bIh6c+wIorZfijIE5t9aVawrOmQCfVD6U awrJpjcL9cl8pSDnCLVRArU= =Gvgd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352729: ITP: cairomm -- C++ wrappers for Cairo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Danilo Piazzalunga wrote: Package: wnpp Version: N/A; reported 2006-02-13 Severity: wishlist Owner: Danilo Piazzalunga [EMAIL PROTECTED] * Package name: cairomm Version : 0.5.0 Upstream Authors: Murray Cumming [EMAIL PROTECTED] The cairomm Development Team * URL : http://www.cairographics.org/cairomm * License : LGPL Description : C++ wrappers for Cairo cairomm provides C++ bindings for the Cairo graphics library, a multi-platform library providing anti-aliased vector-based rendering for multiple target backends. I'm the maintainer of the core cairo packages for debian.It is a supported API which is a good reason to package it. If you want this in Debian and can do the packaging, I might be able to sponsor it for you. I'm not really a C++ developer so I would mostly be only checking it on the packaging side of things. Dave -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD+ou7Q+ySUE9xlVoRAljoAKCoI5NbH0oO1cAgghqU+pLaeZoZjwCfaLas RUVNBMYwA0EZpNnZGpfJaUo= =iP75 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353041: git-core: Please package git 1.2.0
Package: git-core Version: 1.1.5-1 Severity: normal Please can you package git 1.2.0 which has been released at http://www.kernel.org/pub/software/scm/git/ a few days. (and 1.1.6 has been available for 2 weeks at this time). Thanks Dave -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages git-core depends on: ii libc6 2.3.5-13 GNU C Library: Shared libraries an hi libcurl3-gnutls 7.15.1-1 Multi-protocol file transfer libra ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii rcs 5.7-17 The GNU Revision Control System ii zlib1g1:1.2.3-9 compression library - runtime Versions of packages git-core recommends: pn curl none (no description available) pn git-doc none (no description available) ii less 394-1 Pager program similar to more ii openssh-client1:4.2p1-5 Secure shell client, an rlogin/rsh ii patch 2.5.9-4Apply a diff file to an original ii python2.3.5-5An interactive high-level object-o ii rsync 2.6.6-1fast remote file copy program (lik -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351981: muine: Fails to start
On Wed, 2006-02-08 at 16:57 -0500, Benjamin Seidenberg wrote: Package: muine Version: 0.8.3-8 Severity: grave Justification: renders package unusable Muine fails to start after freshly being installed on my system. [EMAIL PROTECTED]:~$ muine ** (muine:19775): WARNING **: No GConf default audio sink key and osssink doesn't work Unhandled Exception: System.Exception: Failed to initialize the audio backend: Could not render default GStreamer audio output sink Your audio or gstreamer configuration is broken. Does audio *sent via gstreamer* work in other apps? in 0x00085 Muine.PlaylistWindow:SetupPlayer () in 0x00188 Muine.PlaylistWindow:.ctor () in 0x0034d Muine.Global:Main (System.String[] args) [EMAIL PROTECTED]:~$ An audio player app that can't find any audio probably shouldn't die like this, but it remains a fatal error, as it can't proceed. Dave signature.asc Description: This is a digitally signed message part
Bug#327407: string-to-double conversion still fails (spins) on 1e-308
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron M. Ucko wrote: reopen 348792 327407 thanks Although the tweak for string-to-double conversion on 64-bit systems that made it into the latest gcj-4.0 upload has been a definite improvement, the new code still fails on at least one input: attempting to convert 1e-308 goes into an infinite loop. ikvm's long-suffering amd64 build now tickles this when attempting to compile DoubleToString.java, so I'm reopening #327407 as well. ikvm 0.24.0.1-1 doesn't use gcj, it uses ecj and I've built it on amd64 myself: $ arch x86_64 $ ikvm -version CLR version: 1.1.4322.2032 (64 bit) System: 1.0.5000.0 IKVM.Runtime: 0.24.0.1 IKVM.GNU.Classpath: 0.24.0.1 ikvm: 0.24.0.1 mscorlib: 1.0.5000.0 GNU Classpath version: 0.20 so I'll be closing 327407 shortly unless you do that yourself first. Dave -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD56CkQ+ySUE9xlVoRApZDAJ4sP/Qgp/KvjHB83prGK5jGZ7PcqQCfScZP r/HBxWF0IetKGZ9nGdn8aoA= =9+dN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351524: libcairo2-dev: cairo_pdf_surface_create and all pdf related functions are not available
Emil Nowak wrote: Package: libcairo2-dev Version: 1.0.2-3 Severity: normal If I try to use some pdf related functions (which are described in libcairo2-doc package). I have error message that this symbol is undefined. It seems that there is nothing related to pdf: $ objdump -T /usr/lib/libcairo.so|grep pdf $ What heppend? pdf support in libcairo was disabled when compiling pacage? If so please enable it. Or at least remove documentation describing those non-exist funcions. They were disabled in the packaging of 1.0.2 (several months ago) because they are not supported upstream, and I didn't want to become their maintainer. PDF and PostScript support are supported in the next release of Cairo which was scheduled to be out by now, but it has not yet got all the release issues shaked out. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347675: Acknowledgement (libcairo2: segv in nautilus)
Andreas Degert wrote: Update: I rebuilt the package libcairo2 (with apt-get -b source ...), now it works. Ok... this is good, but not really very helpful in finding what actually caused the segv. Wwhat broke? Clearly cairo didn't change recently so it must have been something else in the chain. Somebody did an ABI change without a version bump? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328877: python2.3-cairo: Should have cairo.gtk as pytgtk 2.7+ is not on sid yet.
Marco Tulio Gontijo e Silva wrote: Package: python2.3-cairo Version: 1.0.0-1 Severity: normal As pygtk 2.7+ is not on sid yet, it would be good that cairo have cairo.gtk support cause if not there's no way to use cairo + python + gtk. As I was just reviewing the bugs for pycairo I see I hadn't yet commented on this one. cairo is now a requirement for gtk 2.8+ so that is the route that cairo+gtk integration will be going. I don't have any plans to add the cairo.gtk part from here. pygtk 2.7+ still isn't in sid either but it is in experimental. I'd rather not clash with that too as the cairo + gtk work is going on there, from what I read on http://live.gnome.org/PyGTK/WhatsNew28 Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344931: redland-bindings: Request PHP module package
Tim Nowaczyk wrote: Package: redland-bindings Severity: wishlist dpkg-buildpackage does not currently build the php modules that are a part of this source package. Can these modules be built officially? They could. Do you have a preference for which php version? The downside of adding more binding languages is that new versions of redland-bindings have to wait for another big package (perl + python + ruby + php) before it can progress from unstable to testing - but that's a maintainer problem. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339408: python-cairo: PDF, PostScript surfaces not supported
Jamie Wilkinson wrote: import cairo print cairo.HAS_PDF_SURFACE 0 print cairo.HAS_PS_SURFACE 0 print cairo.HAS_GLITZ_SURFACE 0 This makes me a sad panda. Can you please enable all the target formats? Not at present since they are totally unsupported by upstream and I don't want to become their maintainer. However - good news - the PDF and PostScript surfaces are about to be supported in the next stable release of cairo (1.2.0) which is out 'soon'. Glitz is unlikely to be enabled as upstream prefers/expects that the acceleration be done via the RENDER extension on the server. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333259: 333259 is no longer grave
severity 333259 normal thanks As of curl 7.15.0-3, libcurl3-dev has been restored so libraptor1-dev is buildable from source again now (I checked, with a sid pbuilder build). This bug is thus not severe anymore, but the dependency can be updated at next upload to pick one of libcurl3-gnutls or libcurl3-openssl-dev in the dependencies. I'm likely to chose openssl as that's what has worked. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332274: muine and gtk-sharp2 2.3.x
When muine jumped the gun on gtk-sharp2 2.3.91, it did so only for i386; on other architectures, the autobuilders naturally continued to use 1.9.5. ... nope. It requires gtk-sharp2 1.9.2+ and was uploaded with that dependency in the build which is recorded in, for example, the i386 deb. Any 2.3.x series gtk-sharp2 appeared after the last muine was built. If this fails to build muine, please report that as a bug explaining it or update this one. ... As such, could you please reupload the package, preferably with updated build-dependencies to be safe? You don't say what to update. require gtk-sharp2 1.9.x? Also your report was made on amd64 / x86_64 which is not a debian project architecture. Please report bugs against an architecture that the project supports. I'm likely to close this bug without further information. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327407: ikvm: FTBFS on amd64: External Program Failed: ecj (return code was 255):
On Sat, 2005-09-10 at 00:10 +0200, Kurt Roeckx wrote: Package: ikvm Version: 0.18.0.0-2 Severity: important Hi, Your package is failing to build on amd64. I see those things in the build log: [exec] 1. ERROR in ../classtmp/java/lang/Double.java [exec] (at line 73) [exec] public static final double MIN_VALUE = 5e-324; [exec] ^^ [exec] The literal 5e-324 of type double is out of range [exec] -- [exec] -- [exec] 2. ERROR in java/lang/DoubleToString.java [exec] (at line 0) [exec] // NOTE this code was adapted from source code accompanying the article [exec] ^ [exec] Internal compiler error [...] BUILD FAILED - 0 non-fatal error(s), 42 warning(s) /build/buildd/ikvm-0.18.0.0/classpath/classpath.build(45,14): External Program Failed: ecj (return code was 255): Please see the full build log at: http://amd64.ftbfs.de/fetch.php?pkg=ikvmver=0.18.0.0-2arch=amd64stamp=1126226390file=logas=raw So that is a failure with (eclipse) ecj-bootstrap on amd64. I can't test that architecture and the fault lies either with ecj-bootstrap or the GNU classpath sources. There is (as of 14 Sep) a new ecj-bootstrap upstream in sid, maybe you can try again with 3.0.93. (There is also a newer ikvm prepared with a newer GNU classpath source but it requires mono 1.1.9 which is being tested before uploading and it also has the same line in the file that fails to compile.) Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325526: libcairo2: gimp build broken in debian testing
On Mon, 12 Sep 2005, Sven Neumann wrote: Package: libcairo2 Version: 1.0.0-1 Followup-For: Bug #325526 The very same problem happens when I try to build GIMP from CVS on a Debian testing system. The PDF import plug-in that uses poppler fails to build: /usr/bin/../lib/libcairo.so.2: undefined reference to `FT_GlyphSlot_Embolden' As far as I can tell, the problem is that libcairo is built against a newer version of libfreetype6 which is not yet in testing (2.1.7 vs. 2.1.10). The bug is thus a missing dependency. libcairo2 should depend on libfreetype6 = 2.1.10. I've had a check and it seems to be the case. freetype bug #316031 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316031 shows the horror. Given that there seems little chance of freetype 2.1.10 going into testing anytime soon from the number of RC bugs, I think the only solution is to try to rebuild cairo without that function; it's a configure-time test anyway but the rebuild will need some source patching. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325526: undefinedsymbol: FT_GlyphSlot_Embolden
On Mon, 2005-08-29 at 18:22 +1000, jim wrote:
Package: libcairo2
Version: 1.0.0-1
Severity: important
Building openoffice.org SRC680_m125 with GNU/Linux sparc debian/unstable
gcc-4.0 gcj-4.0
Making: ../../unxlngs.pro/lib/libofficebean.so
ccache g++-4.0 -z combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' -shared
-L../../unxlngs.pro/lib -L../lib -L/home/jim/ooo680/solenv/unxlngs/lib
-L/home/jim/ooo680/solver/680/unxlngs.pro/lib
-L/home/jim/ooo680/solenv/unxlngs/lib -L/usr/lib -L/usr/jre/lib/sparc
-L/usr/jre/lib/sparc/client -L/usr/jre/lib/sparc/native_threads
-L/usr/X11R6/lib
.../../unxlngs.pro/slo/officebean_version.o -o
.../../unxlngs.pro/lib/libofficebean.so
.../../unxlngs.pro/slo/com_sun_star_comp_beans_LocalOfficeWindow.o
.../../unxlngs.pro/slo/com_sun_star_beans_LocalOfficeWindow.o -lgcjawt -lgcj
-lstdc++ -ldl -lpthread -lm
rm -f ../../unxlngs.pro/lib/check_libofficebean.so
mv ../../unxlngs.pro/lib/libofficebean.so
.../../unxlngs.pro/lib/check_libofficebean.so
/home/jim/ooo680/solenv/bin/checkdll.sh -L../../unxlngs.pro/lib -L../lib
-L/home/jim/ooo680/solenv/unxlngs/lib
-L/home/jim/ooo680/solver/680/unxlngs.pro/lib
-L/home/jim/ooo680/solenv/unxlngs/lib -L/usr/lib -L/usr/jre/lib/sparc
-L/usr/jre/lib/sparc/client -L/usr/jre/lib/sparc/native_threads
-L/usr/X11R6/lib
.../../unxlngs.pro/lib/check_libofficebean.so
Checking DLL ../../unxlngs.pro/lib/check_libofficebean.so ...: ERROR:
/usr/lib/libcairo.so.2: undefinedsymbol: FT_GlyphSlot_Embolden
dmake: Error code 1, while making '../../unxlngs.pro/lib/libofficebean.so'
'---* tg_merge.mk *---'
ERROR: Error 65280 occurred while making /home/jim/ooo680/bean/native/unix
So a program in the OO.o build called CheckDLL gives an ERROR
libcairo and libfreetype6 are latest.
[EMAIL PROTECTED]:~$ nm -D /usr/lib/libcairo.so | grep FT_GlyphSlot_Embolden
U FT_GlyphSlot_Embolden
[EMAIL PROTECTED]:~$ nm -D /usr/lib/libfreetype.so.6 | grep
FT_GlyphSlot_Embolden
00013dc8 T FT_GlyphSlot_Embolden
Yes it's undefined and libcairo.so has a dynamic library dependency on
libfreetype.so.6 so when you dyload it, it should bring it in and make
it defined:
$ objdump -p /usr/lib/libcairo.so | grep freetype
NEEDED libfreetype.so.6
This should happen automatically if your shared libraries are installed
properly. Trivial test:
$ cat foo.c
#include cairo.h
main () {
FT_GlyphSlot_Embolden();
}
$ gcc -o foo foo.c `pkg-config cairo --libs` `pkg-config cairo --cflags`
$ ./foo
$ ldd ./foo
linux-gate.so.1 = (0xe000)
libcairo.so.2 = /usr/lib/libcairo.so.2 (0xb7f3c000)
libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7e05000)
libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0xb7d98000)
libXrender.so.1 = /usr/lib/libXrender.so.1 (0xb7d9)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0xb7cc5000)
libpng12.so.0 = /usr/lib/libpng12.so.0 (0xb7c9f000)
libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0xb7c7)
libz.so.1 = /usr/lib/libz.so.1 (0xb7c5c000)
libm.so.6 = /lib/tls/i686/cmov/libm.so.6 (0xb7c37000)
/lib/ld-linux.so.2 (0xb7fa)
libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xb7c33000)
libexpat.so.1 = /usr/lib/libexpat.so.1 (0xb7c12000)
I'm struggling to see why this is a bug with libcairo2
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: sparc (sparc64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-sparc64
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Versions of packages libcairo2 depends on:
ii libc6 2.3.5-3GNU C Library: Shared libraries
an
ii libfontconfig12.3.2-1generic font configuration
library
ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared
lib
ii libpng12-01.2.8rel-1 PNG library - runtime
ii libx11-6 6.8.2.dfsg.1-5 X Window System protocol client
li
ii libxrender1 1:0.9.0-2 X Rendering Extension client
libra
ii xlibs 6.8.2.dfsg.1-5 X Window System client libraries
m
ii zlib1g1:1.2.3-3 compression library - runtime
As the dependencies say; libcairo2 needs libfreetype6 installed and you
do have both.
Dave
signature.asc
Description: This is a digitally signed message part
Bug#325379: python-cairo: undefined symbol: cairo_ps_surface_create
Yes, the postscript, PDF and OpenGL backends were removed at cairo 1.0.0 after upstream made them unsupported (for now) and the pycairo bindings need a rebuild to reflect that. Dave signature.asc Description: This is a digitally signed message part
Bug#322858: Incomplete YYSTYPE declaration in header
On Fri, 2005-08-12 at 10:30 -0700, Matt Kraai wrote:
Package: byacc
Version: 20050505-1
Severity: serious
groff fails to build from source because byacc generates an incomplete
declaration of YYSTYPE in the header file. The first attachement
contains the header file it generates. The second attachment contains
a patch that fixes this problem.
Recording the diff in eql_tab.h from byacc-old/byacc-new:
--- eqn_tab.h.orig 2005-08-13 23:42:53.0 +0100
+++ eqn_tab.h 2005-08-13 23:43:13.0 +0100
@@ -56,12 +56,5 @@
#define SET 312
#define GRFONT 313
#define GBFONT 314
-typedef union {
- char *str;
- box *b;
- pile_box *pb;
- matrix_box *mb;
- int n;
- column *col;
-} YYSTYPE;
+ YYSTYPE;
extern YYSTYPE yylval;
This is serious because it prevents groff from building.
OK, shame apt-cache rdepends doesn't show Build-Depends, which is what
byacc is likely most used for :/
I've looked at your patch and don't grok it yet.
Dave
signature.asc
Description: This is a digitally signed message part
