Bug#290923: muine: Could be libxine
On Wed, 19 Jan 2005 20:46:05 -0500, Javier Kohen <[EMAIL PROTECTED]> wrote: > Package: muine > Version: 0.6.3-5 > Followup-For: Bug #290923 > > I'm seeing a similar pattern in totem-xine when playing a CD, so I guess it > could > be libxine that's causing these weird allocations. That's good because I plan to switch to gstreamer0.8 soonish since the API has stopped changing at such a rate. 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#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#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#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#311042: libcairo: New upstream release
On Sat, 2005-06-11 at 16:21 +, ROBERTOJIMENOCA wrote: > > Please package new version 0.5.0. > > > It would maybe be needed to change the shlib version, I cannot tell. > The cairo API is not yet stable. Although there aren't many things left > to be done to have a stable API: > http://cvs.cairographics.org/*checkout*/cairo/TODO > > I think it's better to not change the shlib version because this is > known to be in development and applications should really be changed to > the new API (the old API is not going to be supported) Until the packages already in debian unstable move to the cairo0.5 api, both the 0.4 and 0.5 apis will be needed. cairo0.5 packages are in the NEW queue right now, and the 0.4 ones will remain until nobody is using them. Dave signature.asc Description: This is a digitally signed message part
Bug#314213: vc-svn.el
Yes, please revert this change. It caused emacs to fail to save any version controlled file (svn or not) or do vc operations or allow you to quit (unsaved changes). I reverted to the copy of vc-svn.el in 1.1.4-2 and things are working again. Thanks Dave signature.asc Description: This is a digitally signed message part
Bug#309933: libgpewidget1: request to remove dependency on cairo
Hi Philip On Fri, 20 May 2005, Philip Blundell wrote: > On Fri, 2005-05-20 at 16:39 +0100, Dave Beckett wrote: > > I am the maintainer of the cairo libraries in debian and I have > > recently made the request that they be removed from sarge as the API > > is about to make a big change and it is probably a bad idea to ship > > the old api version in a release: > > http://lists.debian.org/debian-release/2005/05/msg01167.html > > > > Although this request is still under consideration, libgpewidget is > > one of the few (2) apps using cairo going into sarge. I checked the > > libgpewidget1 source and it seems there is alternate code if cairo is > > not available, which was easy for me to enable with $(make) CAIRO=no > > in the build rule. > > > > Can I request libgpewidget is rebuilt without cairo, removing the > > build dependency also. > > Seems reasonable. I'll make that change. Can I ask if you are going to upload this soon? To get cairo removed I need a new libgpewidget upload and need you to request debian-release to add the new version into sarge. There's only a few days left. Cheers Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311182: ikvm: FTBFS: Does not make the libikvm-native packages when running binary-arch.
On Sun, 29 May 2005, Kurt Roeckx wrote: > Package: ikvm > Version: 0.14.0.1-2 > Severity: serious > Tags: experimental > > Hi, > > When only building the architecture specific .debs, it fails to > build because "binary-arch" does nothing. Just running > dpkg-buildpackage -B has this effect. Please can you explain why you are building this experimental mono deb and for what architecture, thanks. The bug will be fixed by an upload shortly. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#272264: tomboy debs for mono 1.0 and mono 1.1
Having got no reply to my status query for a week, I've made some tomboy debs. I looked at the version on mentors but instead decided to start with the ubuntu packaging and go from there, fixing the images problem. I've made a couple of versions now, the most recent one for the mono 1.1 debs that the Debian Mono Group is testing at present. The results are lintian, linda clean and work ok. The debs for mono 1.0 (tomboy 0.3.2-1) mono 1.1 experimental http://debian.meebey.net/mono/ (tomboy 0.3.2-3) are at http://download.dajobe.org/debian/experimental/ I think Tomboy is ready to go into the archive, at least in experimental, probably tracking the mono1 .1 debs. I didn't do the ITP, but if it's still hanging about in a week, I'd like to take it forward. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305459: Intent to maintain ikvm
I intend to maintain ikvm, will try to package it shortly. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305458: Intent to maintain
I intent to maintain nant, will try packaging it shortly. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300656: svn2png packages
I've been packaging these for debian for a long time, hosted at the http://cairographics.org/packages/debian/unstable/ site and my own. I'm a debian developer and maintain the rest of the cairo packages. If you think svg2png is worth adding, I'm happy to do this. Dave signature.asc Description: This is a digitally signed message part
Bug#309674: patch
This seems to be a bug in libpixman not libcairo, which was fixed in
CVS and in the new release that came out yesterday.
It's small enough to include here.
If you can try it out, let me know. It makes your test code run for me.
Dave
--- src/icformat.c.orig 2005-03-02 15:43:33.0 +
+++ src/icformat.c 2005-05-19 15:55:23.0 +0100
@@ -99,7 +99,6 @@
format->id = FakeClientID (0);
*/
format->format_code = format_code;
-format->depth = PICT_FORMAT_BPP(format_code);
switch (PICT_FORMAT_TYPE(format_code)) {
case PICT_TYPE_ARGB:
@@ -148,6 +147,11 @@
/* remaining fields already set to zero */
break;
}
+
+format->depth = _IcOnes ((format->alphaMask << format->alpha) |
+(format->redMask << format->red) |
+(format->blueMask << format->blue) |
+(format->greenMask << format->green));
}
slim_hidden_def(pixman_format_init);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309933: libgpewidget1: request to remove dependency on cairo
Package: libgpewidget1 Version: 0.88-1 Severity: normal I am the maintainer of the cairo libraries in debian and I have recently made the request that they be removed from sarge as the API is about to make a big change and it is probably a bad idea to ship the old api version in a release: http://lists.debian.org/debian-release/2005/05/msg01167.html Although this request is still under consideration, libgpewidget is one of the few (2) apps using cairo going into sarge. I checked the libgpewidget1 source and it seems there is alternate code if cairo is not available, which was easy for me to enable with $(make) CAIRO=no in the build rule. Can I request libgpewidget is rebuilt without cairo, removing the build dependency also. Thanks Dave -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libgpewidget1 depends on: ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii libcairo10.4.0-1 Multi-platform 2D graphics library ii libfontconfig1 2.3.2-1 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgtk2.0-0 2.6.4-3 The GTK+ graphical user interface ii libpango1.0-01.8.1-1 Layout and rendering of internatio ii libpixman1 0.1.4-1 Cairo pixel manipulation library ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libx11-6 4.3.0.dfsg.1-13 X Window System protocol client li ii libxrender1 1:0.8.3-1 X Rendering Extension client libra ii xlibs4.3.0.dfsg.1-13 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284205: Version 0.3 is available!
On Sat, 2005-01-22 at 12:40 +0300, Dan Korostelev wrote: > Cairo 0.3 was just released, please, update your packages! > Thanks for maintaining! I've made some experimental packages here with -0.1 release http://cairographics.org/packages/debian/ I am hoping my Debian developer account gets created soon rather than I have to ask my sponsor instead. At that point I'll upload them with a -1 release. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300541: #300541: muine: "Could not find the volume element in the GstPlay pipeline"
On Sun, 2005-03-20 at 22:01 +0200, Gintautas Miliauskas wrote: > Package: muine > Version: 0.6.3-7 > Followup-For: Bug #300541 > > I am experiencing the same problem. It appears that I can't even downgrade > easily because the version in testing is the same as in unstable. There is no version of muine in testing, it was removed months ago along with all other mono packages to prevent it entering sarge. Sounds to me like gstreamer0.8's "stable" api has broken things again. Dave signature.asc Description: This is a digitally signed message part
Bug#300944: python-librdf breaks with latest libcurl3 in sarge and sid
On Tue, 2005-03-22 at 15:25 -0500, Jeff Licquia wrote: > Package: python2.3-librdf > Version: 1.0.0.2-1 > Tags: sarge, sid > Severity: grave > Justification: renders package unusable > > [EMAIL PROTECTED]:~$ python > Python 2.3.4 (#2, Dec 3 2004, 13:53:17) > [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import RDF > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.3/site-packages/RDF.py", line 130, in ? > import Redland > ImportError: /usr/lib/libcurl.so.3: undefined symbol: tld_strerror > >>> > [EMAIL PROTECTED]:~$ dpkg --list python2.3-librdf libcurl3 > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > uppercase=bad) > ||/ Name VersionDescription > +++-==-==- > ii python2.3-libr 1.0.0.2-1 Python 2.3 language bindings for the Redland > ii libcurl3 7.13.1-1 Multi-protocol file transfer library, now wi Can you please try it with the actual latest one in sarge - 7.13.1-2 The changelog for that says: * Rebuilt to get the correct libidn11 dependency (closes: #299348). which could be the missing symbol as the bug message mentions tld_strerror. > [EMAIL PROTECTED]:~$ sudo dpkg -i ~darrint/libcurl3_7.13.0-2_i386.deb > dpkg - warning: downgrading libcurl3 from 7.13.1-1 to 7.13.0-2. > (Reading database ... 70836 files and directories currently installed.) > Preparing to replace libcurl3 7.13.1-1 (using .../libcurl3_7.13.0-2_i386.deb) > ... > Unpacking replacement libcurl3 ... > Setting up libcurl3 (7.13.0-2) ... > > [EMAIL PROTECTED]:~$ python > Python 2.3.4 (#2, Dec 3 2004, 13:53:17) > [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import RDF > >>> > [EMAIL PROTECTED]:~$ Cheers Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316308: fakeroot scripts do not invoke shell correctly
Package: fakeroot Version: 1.4 Severity: grave Justification: renders package unusable The fakeroot scripts do not have the #! prefix before the path. This causes fakeroot to invoke a shell, waiting for user response (^D / exit) before actually running the program requested. $ mkdir foo $ cd foo $ fakeroot ls sh-3.00$ type ^D or exit and the ls runs Expected result, ls runs without user interaction. $ head -1 /usr/bin/fakeroot-sysv /bin/sh $ head -1 /usr/bin/fakeroot-tcp /bin/sh Adding #! to the start of those scripts makes them work again. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakeroot depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an fakeroot recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318593: oregano: Depends on unavailable libcairo1
Package: oregano Version: 0.40.0-5 Severity: normal libcairo1 (cairo 0.4.0) has been removed from sid and replaced with libcairo0.5.1 (cairo 0.5.1). oregano is now uninstallable. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290923: muine: Huge (virtual) memory leak
muine has been switched to use the gstreamer backend and is now using a much newer mono runtime. Has this problem been seen with muine 0.8.3? Dave signature.asc Description: This is a digitally signed message part
Bug#319779: ITP: pycairo -- python language bindings for the Cairo vector graphics library
Package: wnpp Severity: wishlist Owner: Dave Beckett <[EMAIL PROTECTED]> Package name: pycairo Version : 0.5.1 Upstream Author : James Henstridge, Steve Chaplin, Kevin Worth URL : http://cairographics.org/snapshots/ License : LGPL / MPL Description : Python language bindings for the Cairo vector graphics library This package contains modules that allow you to use the Cairo vector graphics library in Python programs. I've been packaging this for several years, tracking cairo snapshots. ITP now as it seems to be needed for pygtk and cairo is heading towards a stable API. Initial packages are available from http://cairographics.org/packages/debian/unstable/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311133: please build poppler 0.3.3 against cairo 0.5.1
I'm the maintainer of the cairo packages in debian and I've just replaced cairo0.4.0 with cairo0.5.1 after discussion with ftpmasters. poppler 0.3.1 is thus no longer buildable from source. I downloaded poppler 0.3.3 and tried it against the new packages using the debian diff.gz and it builds OK. I didn't test it. Dave signature.asc Description: This is a digitally signed message part
Bug#300541: muine: Puhulease fix this bug :)
On Sun, 03 Apr 2005 00:01:04 +0200 Joergen Scheibengruber <[EMAIL PROTECTED]> wrote: > Subject: muine: Puhulease fix this bug :) > Followup-For: Bug #300541 > Package: muine > Version: 0.6.3-7 > > I experience this bug, too. It's very annoying :( > Could you please look into this? It seems there is a fix for something like this in a patch from gentoo, to fix the gstreamer breakage. Can you try out the muine_0.6.3-8_i386.deb at http://download.dajobe.org/debian/unstable/ and if it's good, I'll put it in the archive. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#272264: tomboy debs, sponsor offer
Are there any public debs of this yet? We were discussing it on #debian-mono and I checked the ITP for news.Good to see the icon has been sorted out. There's no chance of it reaching sarge, that's clear as it depends on mono which isn't going in. However if it goes into unstable that'd be great. I'm a DD and happy to sponsor it. 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#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#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=ikvm&ver=0.18.0.0-2&arch=amd64&stamp=1126226390&file=log&as=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#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#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
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#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
Bug#276096: eclipse 3.1 in debian
After much searching and broken links, I see eclipse 3.1 is in ubuntu. Here's the crucial link: ftp://ftp.ubuntu.com/ubuntu/pool/universe/e/eclipse/ Is there any reason why this can't be packaged for debian now? Who is (intending to) maintain it? debian-java seemed rather quiet about it, and was one of the sources of broken-links. Dave signature.asc Description: This is a digitally signed message part
Bug#320710: ikvm: FTBFS: Trying to write outside the source dir.
On Sun, 2005-07-31 at 23:30 +0200, Kurt Roeckx wrote: > Package: ikvm > Version: 0.16.0.0-1 > Severity: important > > Hi, > > Building the package is failing on amd64. I see this in the > build log, and assume that's why it's failing: > [csc] Unhandled Exception: > System.Security.Cryptography.CryptographicException: Could not create user > key store '/home/buildd/.config/.mono/keypairs'. ---> > System.UnauthorizedAccessException: Access to the path "/home/buildd/.config" > is denied. > > I think trying to write things outside of the source tree really > shouldn't be done when building something. This isn't a debian project buildd http://buildd.debian.org/build.php?pkg=ikvm Can you please point me to your amd64 build log? Dave signature.asc Description: This is a digitally signed message part
Bug#276096: eclipse 3.1 in debian
After I emailed the bug, I ported the ubuntu packages to debian, fixing a few problems with dependencies. It takes about 1.3G of disk, 500M+ of /tmp and 100Ms of memory and 30+ minutes to build on system. and still isn't quite working yet: $ /usr/bin/eclipse /usr/bin/eclipse: line 4: /usr/share/java-common/java-common.sh: No such file or directory /usr/bin/eclipse: line 5: jvm_find: command not found which seems to be caused by using files in the java-common package from ubuntu (0.23ubuntu3) which are not in the debian one (0.23). I also think eclipse-ecj should Conflict: and Replace: ecj-bootstrap so that installing eclipse-ecj kicks out ecj-bootstrap. The resulting binaries I'm not wanting to host myself but 've put the diff I've got so far at http://people.debian.org/~dajobe/eclipse/ I'm not very interested in maintaining it, but as the maintainer of ikvm I'd like it build as ikvm's latest release now needs either ecj-bootstrap or eclipse-ecj to compile. I'm presently using the former. Dave signature.asc Description: This is a digitally signed message part
Bug#318293: Depends on unavailable cairo
poppler is still depending on a libcairo binary removed some time ago.
libcairo0.6.0{,dev} are the packages for latest cairo version 0.6.0 that
I've just added to sid (I'm the cairo maintainer). Upstream cairo
developers are heading for 1.0 and a stable API "soon" so there will
definitely be more cairo packages and possibly more minor API changes in
them.
Dave
signature.asc
Description: This is a digitally signed message part
Bug#321058: oregano: Depends on unavailable libcairo0.5.1
Package: oregano Version: 0.40.4-1 Severity: normal For your information, libcairo0.5.1 (cairo 0.5.1) has just been removed from sid and replaced with libcairo0.6.0 (cairo 0.6.0) so oregano is now uninstallable. Dave -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- 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#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#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 > #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
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#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#282208: Bug check
Redland bindings 1.0.0.1-1 (source) and python2.3-librdf 1.0.0.1-1 (binary package) are now in sid. Could you maybe confirm that you don't get your bug/crash with this version? It works for me, as it did with the version your reported against. Thanks Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295850: savelog: ignores the -p preserve option on new log files
Package: debianutils Version: 2.12.0 Severity: important # touch foo # chown mail.adm foo # savelog -p -c 10 foo chown: failed to get attributes of `--': No such file or directory chmod: failed to get attributes of `--': No such file or directory Rotated `foo' at Fri Feb 18 15:07:02 GMT 2005. # ls -l foo* -rw--- 1 root root 0 Feb 18 15:07 foo -rw-r--r-- 1 mail adm 0 Feb 18 15:06 foo.0 When this happened to exim3 this morning at 3am, it no longer could write it's log files and all mail delivery stopped. The -p option should preserve the permissions on the new file which it did in previous versions. I tried 2.11.2 and got: # rm foo* # touch foo # chown mail.adm foo # savelog -p -c 10 foo Rotated `foo' at Fri Feb 18 15:11:41 GMT 2005. # ls -l foo* -rw-r--r-- 1 mail adm 0 Feb 18 15:11 foo -rw-r--r-- 1 mail adm 0 Feb 18 15:11 foo.0 Looks like some argument parsing is broken given the errors about '--' Dave -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages debianutils depends on: ii coreutils 5.2.1-2 The GNU core utilities ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295850: savelog: ignores the -p preserve option on new log files
On Fri, 18 Feb 2005, Clint Adams wrote: > > chown: failed to get attributes of `--': No such file or directory > > chmod: failed to get attributes of `--': No such file or directory > > This might have been fixed in 2.12.1; can you confirm? Sorry, no. Taking http://incoming.debian.org/debianutils_2.12.1_i386.deb it fails in exactly the same way # touch foo # chown mail.adm foo # savelog -p -c 10 foo chown: failed to get attributes of `--': No such file or directory chmod: failed to get attributes of `--': No such file or directory Rotated `foo' at Fri Feb 18 19:14:35 GMT 2005. # ls -l foo* -rw--- 1 root root 0 Feb 18 19:14 foo -rw-r--r-- 1 mail adm 0 Feb 18 19:14 foo.0 Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#260044: Muine 0.8.0+ needs dbus-sharp
I am the maintainer of the muine[1] music player in debian - packages at [2]. muine versions 0.8.0 (0.6.x are in the archive) now require dbus-sharp in order to build and run. I'd appreciate if a dbus-sharp binary package was made part of the standard dbus packaging. I've used the patch in this bug successfully to make my own dbus debs which I've put at dbus-0.22 dir below http://www.ilrt.bristol.ac.uk/people/cmdjb/2004/muine/devel/ It's named libdbus-cil following the debian mono packaging style (and the patch) and works fine for me building muine here. Aside: Muine 0.7.0+ depends on an unstable gtk# version so that will have to be in the debian archive before the newest muine can be added. Thanks Dave [1] http://muine.gooeylinux.org/ [2] http://packages.qa.debian.org/m/muine.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#248706: Outstanding ITP - glitz
On Sat, 01 Jan 2005 14:28:00 -0500, Justin Pryzby <[EMAIL PROTECTED]> wrote: > This is a batch mailing regarding your stated ITP (Intent To Package) > of the following Debian package; I apologize in advance if it is sent > in error. > > glitz -- OpenGL accelerated 2D graphics library > > Do you still intend to create this package? If so, please keep the > bugtracking system informed of progress and delays. ITPs which are > just waiting for a sponsor should be tagged 'patch'; I recommend the > bts script from the devscripts package. > > If not, please retitle to RFP (Request For Package), or close the bug, > as is appropriate. > > Note that I'm not personally interested in this package; I just want > to keep the WNPP area well-pruned. Feel free to respond to me > directly, though (but also Cc: the bug if appropriate). In reply: I'm waiting to become a DD before uploading this rather than bug my sponsor more. I've been packaging it for a long time at; http://cairographics.org/packages/debian/ It looks like this closer than it was recently since I completed the new maintainer process months ago, an account looks nearer. In more relevant news, the newer cairo is using more of glitz and will benefit from it. The interface isn't considered stable yet by the cairo developers but stable-ish, so it'll need careful build checking. 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#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#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#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#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#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#388116: Patch in #383034 is not helpful
Jérémy Bobbio wrote: > Hi! > > I can reproduce this bug. I also tried to build pan against a libcairo2 > with the patch presented in #383034 and it still crash. > > The backtrace is totally unhelpfull, though. :( I agree it isn't. It must have been corrupted before you got the crash. Maybe try duplicating the crash inside valgrind where it might report where the corruption happened. There is a feeling that this kind of thing might be related to the fonts in use which is why it's hard to duplicate. pan works for me just fine local and remove via a powerpc X server. Dave
Bug#388116: Patch in #383034 is not helpful
Jérémy Bobbio wrote:
> On Sat, Oct 07, 2006 at 03:40:43PM -0700, Dave Beckett wrote:
>>> I can reproduce this bug. I also tried to build pan against a libcairo2
>>> with the patch presented in #383034 and it still crash.
>>>
>>> The backtrace is totally unhelpfull, though. :(
>> I agree it isn't. It must have been corrupted before you got
>> the crash. Maybe try duplicating the crash inside valgrind
>> where it might report where the corruption happened.
>>
>> There is a feeling that this kind of thing might be related
>> to the fonts in use which is why it's hard to duplicate. pan
>> works for me just fine local and remove via a powerpc X server.
>
> Attached you will find the output of strace and valgrind on my system
> (PowerPC).
>
> They are not enlightening, though.
Yes it is, since the faults are happening somewhere where there's
a fix for it in upstream GIT sources:
> ==19140== Invalid read of size 1
> ==19140==at 0xF7DC9BC: _cairo_xlib_surface_add_glyph
> (cairo-xlib-surface.c:2455)
> ==19140==by 0xF7DD464: _cairo_xlib_surface_show_glyphs
> (cairo-xlib-surface.c:2824)
> ==19140==by 0xF7BDF84: _cairo_surface_show_glyphs (cairo-surface.c:1820)
> ==19140==by 0xF7B18A4: _cairo_gstate_show_glyphs (cairo-gstate.c:1449)
> ==19140==by 0xF7AC488: cairo_show_glyphs (cairo.c:2539)
> ==19140==by 0xF8FA0F0: (within /usr/lib/libpangocairo-1.0.so.0.1400.5)
> ==19140==by 0xF847990: pango_renderer_draw_glyphs (in
> /usr/lib/libpango-1.0.so.0.1400.5)
> ==19140==by 0xF8F93F0: (within /usr/lib/libpangocairo-1.0.so.0.1400.5)
> ==19140==by 0xFA53BD0: (within /usr/lib/libgdk-x11-2.0.so.0.800.9)
> ==19140==by 0xF847990: pango_renderer_draw_glyphs (in
> /usr/lib/libpango-1.0.so.0.1400.5)
> ==19140==by 0xF847FC8: pango_renderer_draw_layout_line (in
> /usr/lib/libpango-1.0.so.0.1400.5)
> ==19140==by 0xF848208: pango_renderer_draw_layout (in
> /usr/lib/libpango-1.0.so.0.1400.5)
I've uploaded an experimental cairo 1.2.4-3 with this fix. Maybe you
can try it out and see if this fixes it.
Since you are on powerpc you might have to compile it yourself from
sources since experimental packages are not generally autobuilt.
The patch is attached.
Dave
#!/bin/sh /usr/share/dpatch/dpatch-run
## 01-cairo_xlib_surface_add_glyph.patch by Dave Beckett <[EMAIL PROTECTED]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix miscounting in loop in _cairo_xlib_surface_add_glyph()
--- 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.c2006-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#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#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#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#737261: ITP: nghttp2 -- HTTP/2 library
Package: wnpp Severity: wishlist Owner: Dave Beckett Package name: nghttp2 Version : 0.2.0 Upstream Author : Tatsuhiro Tsujikawa 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#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#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#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#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#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#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#454800: More info needed
>Firefox stopped displaying some pages correctly on updating from >libcairo2 version 1.4.10-1 . >Some text is missing. Downgrading helps > >Sample pages: >www.debian.org Never was able to duplicate this - far too vague. Please try 1.4.10-1.3 and see if that fixed what you saw. Otherwise, provide a lot more information: 1) Exact URIs of "some pages" 2) Description of what is not correct 3) Screenshots of problem Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454575: Please check if fixed
> Program received signal SIGFPE, Arithmetic exception. > [Switching to Thread 0xb6d996b0 (LWP 4198)] > 0xb725dcd2 in _get_bitmap_surface (bitmap=0x83efe34, own_buffer=0, > font_options=0x844d358, surface=0xbfcfe02c) > at /home/slomo/projects/debian/tmp/libcairo-1.4.10/src/cairo-ft-font.c:745 > 745 data = _cairo_malloc_ab (height, stride); This crash was introducer in the NMU 1.4.10-1.1 and probably fixed in a later NMU, please can you check libcairo 1.4.10-1.3 or later. 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#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#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#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#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#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#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#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=551202&r1=541552&r2=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#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_string, > std::allocator >, 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_string, > std::allocator >, 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_string, > std::allocator >, 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_string, > std::allocator >, 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#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#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#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#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#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#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#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#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#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#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#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#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 >> #8 cairo_draw_with_xlib (cr=0xbc55ff8, callback=0xb79c4698 , 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#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#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#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=9660&view=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#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 (no description available) pn git-doc(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]
