Bug#429617: installation failes
This bug is gone with 4.67-4, so it may be closed i think. Thanks for your help Marc. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430185: exim4-doc-html: dummy bug to keep package out of testing
Package: exim4-doc-html Version: 4.67-1 Severity: serious Justification: maintainer discretion exim4 4.67 is not yet in testing, hence the docs for exim4 4.67 need to stay out as well. Dummy bug. Greetings Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429617: marked as done (exim4-config installation fails (postinst exit status 1))
Your message dated Sat, 23 Jun 2007 08:38:36 +0200 with message-id [EMAIL PROTECTED] and subject line Bug#429617: installation failes has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: exim4-config Version: 4.67-3 Severity: serious --- Please enter the report below this line. --- i just tried to install exim4 and it did not work: Setting up exim4-config (4.67-3) ... dpkg: error processing exim4-config (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: exim4-config E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up exim4-config (4.67-3) ... dpkg: error processing exim4-config (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: exim4-config after that the installation of the rest of exim4 failes too. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.21.5 Debian Release: lenny/sid 990 unstablewww.debian-multimedia.org 990 unstableftp2.de.debian.org 990 unstableftp.debian-unofficial.org 500 testing ftp2.de.debian.org 500 experimentalwww.debian-multimedia.org 1 experimentalftp2.de.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== debconf (= 0.5) | 1.5.13 OR debconf-2.0| adduser| 3.102 ---End Message--- ---BeginMessage--- Version: 4.67-4 Submitter reports in private mail that the issue is gone in 4.67-4. Looks like the patch to update-exim4.conf helped. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 ---End Message---
Bug#429617: installation failes
Version: 4.67-4 Submitter reports in private mail that the issue is gone in 4.67-4. Looks like the patch to update-exim4.conf helped. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430186: Upgrading to dbus 1.1.1 breaks some gnome-system-tools.
Package: gnome-system-tools Version: 2.18.1-1 Severity: grave Justification: renders package unusable -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages gnome-system-tools depends on: ii gconf22.18.0.1-3 GNOME configuration database syste ii libart-2.0-2 2.3.19-3 Library of functions for 2D graphi ii libatk1.0-0 1.18.0-2 The ATK accessibility toolkit ii libbonobo2-0 2.18.0-2 Bonobo CORBA interfaces library ii libbonoboui2-02.18.0-5 The Bonobo UI library ii libc6 2.5-11 GNU C Library: Shared libraries ii libcairo2 1.4.8-1The Cairo 2D vector graphics libra ii libdbus-1-3 1.1.0-1simple interprocess messaging syst ii libfontconfig12.4.2-1.2 generic font configuration library ii libfreetype6 2.2.1-6FreeType 2 font engine, shared lib ii libgconf2-4 2.18.0.1-3 GNOME configuration database syste ii libglade2-0 1:2.6.1-1 library to load .glade files at ru ii libglib2.0-0 2.12.12-1 The GLib library of C routines ii libgnome-keyring0 0.8.1-2GNOME keyring services library ii libgnome2-0 2.18.0-4 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-3 A powerful object-oriented display ii libgnomeui-0 2.18.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-01:2.18.1-2 GNOME Virtual File System (runtime ii libgtk2.0-0 2.10.13-1 The GTK+ graphical user interface ii libice6 1:1.0.3-2 X11 Inter-Client Exchange library ii libiw29 29~pre21-2 Wireless tools - library ii libnautilus-extension12.18.1-3 libraries for nautilus components ii liboobs-1-3 2.18.1-2 GObject based interface to system- ii liborbit2 1:2.14.7-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.16.4-1 Layout and rendering of internatio ii libpng12-01.2.15~beta5-2 PNG library - runtime ii libpopt0 1.10-3 lib for parsing cmdline parameters ii libsm62:1.0.3-1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor1 1:1.1.8-2 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxfixes31:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxi61:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxml2 2.6.29.dfsg-1 GNOME XML library ii libxrandr22:1.2.1-1 X11 RandR extension library ii libxrender1 1:0.9.2-1 X Rendering Extension client libra ii perl 5.8.8-7Larry Wall's Practical Extraction ii zlib1g1:1.2.3-15 compression library - runtime Versions of packages gnome-system-tools recommends: ii gksu 2.0.0-4graphical frontend to su ii gnome-control-center 1:2.18.1-1 utilities to configure the GNOME d -- no debconf information When I upgraded to dbus and associated lib 1.1.1, some tools from gnome-system-tools do not display any information at all. When I downgraded bach to dbus 1.1.0, everything works again. The error message signaled in the console if from liboost which claims that it does not get answer from the bus. The tools is tried to use which do not display any informations are : network-admin and user-admin. I have not tested the others. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424471:
Rmic has apparently drifted in and out of kaffe/GNU classpath over time. I say we just wait for GPL Sun Java and fix it then. Or punt the Lucene package for Lucene2 if dependencies allow it, and Lucene2 gets into main (again, depending on GPL Sun Java) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430188: smarteiffel2: package fails to install
Package: smarteiffel2 Version: 2.2.99.beta3.2.svn8415-1 Severity: grave Justification: renders package unusable Package installation fails with this error message: ** Fatal Error: Unknown loadpath in /usr/lib/smarteiffel2/lib/loadpath.se: /usr/lib/smarteiffel2/lib/vision/loadpath.se (resolved as //usr/lib/smarteiffel2/lib/vision/loadpath.se). I tried to install smarteiffel2-vision because of this error, but it still fails: ** Warning: Classes path set more than once: /usr/lib/smarteiffel2/lib/loadpath.se -- ** Fatal Error: Double definition of feature to_internals. The source lines involved by the message are the following: Line 399 column 9 in ANY (/usr/lib/smarteiffel2/lib/kernel/any.e): frozen to_internals: INTERNALS is Should I report the second error as a separate bug ? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages smarteiffel2 depends on: ii gcc 4:4.1.2-2 The GNU C compiler ii libc6 2.5-11 GNU C Library: Shared libraries ii libc6-dev 2.5-11 GNU C Library: Development Librari ii libncurses5-dev 5.6-3 Developer's libraries and docs for smarteiffel2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 430186
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.5 tags 430186 + confirmed Bug#430186: Upgrading to dbus 1.1.1 breaks some gnome-system-tools. There were no tags set. Tags added: confirmed End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430186: Upgrading to dbus 1.1.1 breaks some gnome-system-tools.
tags 430186 + confirmed stop With current sid, I get: (users-admin:20537): Liboobs-WARNING **: There was an unknown error communicating with the backends: Message did not receive a reply (timeout by message bus) (users-admin:20537): Liboobs-WARNING **: There was an unknown error communicating with the backends: Message did not receive a reply (timeout by message bus) I don't see why the DBus version changes anything. -- Loïc Minier
Processed: Re: Bug#430186: Upgrading to dbus 1.1.1 breaks some gnome-system-tools.
Processing commands for [EMAIL PROTECTED]: tags 430186 + confirmed Bug#430186: Upgrading to dbus 1.1.1 breaks some gnome-system-tools. Tags were: confirmed Tags added: confirmed stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430200: scsitools: Syntax error in rescan-scsi-bus.sh makes system unusable (Input/output error)
Package: scsitools Version: 0.9-1.1 Severity: grave Tags: patch Justification: renders package unusable Running /sbin/rescan-scsi-bus.sh makes my (and most likely every) system unusable, I get input/output errors when trying to run programs after I ran rescan-scsi-bus.sh. The reason for this behavior is a syntax change for sg_inq; as of sg3-utils-1.24-1, it doesn't accept -36 anymore, but only --len=36. PATCH: Change INQ=`sg_inq -36 /dev/$SGDEV` to INQ=`sg_inq --len=36 /dev/$SGDEV` in /sbin/rescan-scsi-bus.sh. And while you're at it, you could append 2/dev/null to the two lines echo scsi remove-single-device $devnr /proc/scsi/scsi and echo scsi add-single-device $devnr /proc/scsi/scsi which will make the ugly error message line 183: echo: write error: Invalid argument vanish that appears for each unsuccessfully tested ID if there are narrow SCSI channels present when scanning with -w. If I chose the wrong severity and/or tags, please let me know. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages scsitools depends on: ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii libc6 2.5-9+b1 GNU C Library: Shared libraries ii util-linux2.12r-19 Miscellaneous system utilities Versions of packages scsitools recommends: ii tk8.3 [wish] 8.3.5-6Tk toolkit for Tcl and X11, v8.3 - ii tk8.4 [wish] 8.4.12-1 Tk toolkit for Tcl and X11, v8.4 - -- debconf information: scsitools/info: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429784: [Pkg-alsa-devel] Bug#429784: rmmod snd_via82xx modprobe snd_via82xx
On Fri, 22 Jun 2007 the mental interface of Kingsley G. Morse Jr. told: kernel 2.6.18-4-k7 ii alsa-base 1.0.13-1ALSA driver configuration files ii alsa-modules-2.4.19-aa10.9.0rc6+3+p0+10.00.Custom Advanced Linux Sound Architecture (drivers) ii alsa-modules-2.4.27-1-k7 1.0.6a+5ALSA driver modules ii alsa-oss 1.0.12-1ALSA wrapper for OSS applications ii alsa-source0.9.0rc6-3 ALSA driver source ii alsa-utils 1.0.9a-4ALSA utilities rc alsaconf 0.4.3b-4ALSA configurator [...] ii linux-sound-base 1.0.9b-4base package for ALSA and OSS sound systems [...] Looks like you're running etch? Please install at least: apt-get install -t stable libasound2 alsa-utils alsa-base alsa-source Remove old alsaconf, which isn't really needed: apt-get remove --purge alsaconf If you're using Debian's kerneldrivers, your soundcard might be usable now. Otherwise build your soundcard with fresh intalled alsa-source package. On Fri, 22 Jun 2007 the mental interface of Kingsley G. Morse Jr. told: On 06/22/07 19:17, Elimar Riesebieter wrote: Your installation seems to be a chaos which should be sorted by a clean update/upgrade first! Dear Elimar, You're not the first person to recommend an upgrade, and I'm sure you won't be the last. Here's the big but. BUT, apt-get check reports no broken dependencies, and an apt-get upgrade might Hey, Iam running sid (unstable) on servers. Very stable, man ;) Your installation is mixed up back from woody to some lenny packages. Maybe there are some Potato packages flowing around ? I am wondering whether this works anyway. You're done with an apt-get update apt-get dist-upgrade. If you then have ALSA probs, you're welcome to help you ;) But your mixed up installation isn't supportable for a maintainer, though. Elimar -- .~. /V\ L I N U X /( )\ Phear the Penguin ^^-^^ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430210: mhc-utils: Uninstallable because postinst fails
Package: mhc-utils Version: 0.25.1+20070220-1 Severity: grave Justification: renders package unusable Postinst fails and that makes the packages uninstallable: Unpacking mhc-utils (from .../mhc-utils_0.25.1+20070220-1_amd64.deb) ... Setting up mhc-utils (0.25.1+20070220-1) ... dpkg: error processing mhc-utils (--configure): subprocess post-installation script returned error exit status 10 Errors were encountered while processing: mhc-utils E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mhc-utils depends on: ii libc6 2.5-9 GNU C Library: Shared libraries ii libgtk2-ruby 0.15.0-1.1 GTK+ bindings for the Ruby languag ii libpisock90.12.2-9 library for communicating with a P ii libruby1.81.8.6-1+b1 Libraries necessary to run Ruby 1. ii ruby1.8 1.8.6-1+b1 Interpreter of object-oriented scr Versions of packages mhc-utils recommends: ii mhc0.25.1+20070220-1 Message Harmonized Calendaring sys -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430210: mhc-utils: Uninstallable because postinst fails
On June 23, 2007 at 1:39PM +0200, jeroen (at dekkers.cx) wrote: Package: mhc-utils Version: 0.25.1+20070220-1 Severity: grave Justification: renders package unusable Postinst fails and that makes the packages uninstallable: Unpacking mhc-utils (from .../mhc-utils_0.25.1+20070220-1_amd64.deb) ... Setting up mhc-utils (0.25.1+20070220-1) ... dpkg: error processing mhc-utils (--configure): subprocess post-installation script returned error exit status 10 Errors were encountered while processing: mhc-utils E: Sub-process /usr/bin/dpkg returned an error code (1) Hmm, I cannot reproduce this bug. mhc-utils is installable on my environment (sid, i386). Anyway, I'll cleanup mhc-utils.postinst to fix this bug in the next upload. Thanks, -- Tatsuya Kinoshita pgpSVuEKyr8gu.pgp Description: PGP signature
Bug#427359: please trigger rebuilds of opencv on !m68k
Hi, it should help fixing http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427359. Thanks, Torsten -- blog: http://twerner.blogspot.com/ homepage: http://www.twerner42.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430217: Fails to build xdpyinfo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: xbase-clients Version: 1:7.2.ds2-2 Severity: serious Justification: no longer builds from source A build gives the following error. A manual build of xdpyinfo works well. ... xdpyinfo checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for XDPYINFO... yes checking for DPY_X11... yes checking for DPY_XEXT... yes checking for X11/extensions/multibuf.h... yes checking for X11/extensions/XShm.h... yes checking for DPY_XKB... yes checking for X11/extensions/XKB.h... yes checking for X11/XKBlib.h... yes checking for DPY_XF86VIDMODE... yes checking for X11/extensions/xf86vmode.h... yes checking for X11/extensions/xf86vmstr.h... yes checking for DPY_XF86DGA... yes checking for X11/extensions/xf86dga.h... yes checking for X11/extensions/xf86dgastr.h... yes checking for DPY_XF86MISC... no not found checking for DPY_XINPUT... yes checking for X11/extensions/XInput.h... yes checking for DPY_XRENDER... yes checking for X11/extensions/Xrender.h... yes checking for DPY_XINERAMA... yes checking for X11/extensions/Xinerama.h... yes checking for DPY_DMX... no not found checking for DPY_XPRINT... no not found checking for DPY_XTST... yes checking for X11/extensions/record.h... yes checking build system type... i486-pc-linux-gnu checking host system type... i486-pc-linux-gnu configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands make[1]: Entering directory `/misc/build/xbase-clients-7.2.ds2/xdpyinfo-obj-i486-linux-gnu' /usr/bin/make all-am make[2]: Entering directory `/misc/build/xbase-clients-7.2.ds2/xdpyinfo-obj-i486-linux-gnu' if gcc -DHAVE_CONFIG_H -I. -I../xdpyinfo -I.-Wall -g -O2 -MT xdpyinfo.o -MD -MP -MF .deps/xdpyinfo.Tpo -c -o xdpyinfo.o ../xdpyinfo/xdpy info.c; \ then mv -f .deps/xdpyinfo.Tpo .deps/xdpyinfo.Po; else rm -f .deps/xdpyinfo.Tpo; exit 1; fi ../xdpyinfo/xdpyinfo.c:399: warning: 'hasExtension' defined but not used gcc -Wall -g -O2 -o xdpyinfo xdpyinfo.o -lXext -lX11 -lXtst -lXext -lX11 -lXxf86vm -lXxf86dga-lXi -lXrender -lX11 -lXineram a -lXtst sed -e 's|__vendorversion__|xdpyinfo 1.0.1 X Version 11|' -e 's|__xorgversion__|xdpyinfo 1.0.1 X Version 11|' -e 's|__xservername__|Xorg|g' -e 's| __xconfigfile__|xorg.conf|g' -e 's|__projectroot__|/usr|g' -e 's|__apploaddir__||' -e 's|__appmansuffix__|1|g' -e 's|__libmansuffix__|3|g' -e 's|__adminma nsuffix__|8|g' -e 's|__miscmansuffix__|7|g' -e 's|__filemansuffix__|5|g' ../xdpyinfo/xdpyinfo.man xdpyinfo.1 make[2]: Leaving directory `/misc/build/xbase-clients-7.2.ds2/xdpyinfo-obj-i486-linux-gnu' make[1]: Leaving directory `/misc/build/xbase-clients-7.2.ds2/xdpyinfo-obj-i486-linux-gnu' xdriinfo checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking return type of signal handlers... void checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for XDRIINFO... yes checking for library containing glXGetProcAddressARB... no configure: error: cannot find GL library - make sure Mesa or other OpenGL package is installed See `config.log' for more details. make: *** [build-stamp] Fehler 1 debuild: fatal error at line 1228: debian/rules build failed - -- System Information: Debian Release: 4.0
Processed: tagging 422125
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.5 tags 422125 + lenny sid Bug#422125: bcron: FTBFS: tests are not timezome-aware Tags were: patch Tags added: lenny, sid End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 423742
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.5 tags 423742 + lenny sid Bug#423742: avifile: FTBFS: i386: ../../include/avm_map.h:220: error: 'struct avm::avm_mapconst char*, int, avm::AvmOutput::AvmOutputPrivate::Less, .. There were no tags set. Tags added: lenny, sid End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 420060
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.5 tags 420060 + lenny sid Bug#420060: avr-libc: FTBS due missing epstopdf Tags were: patch Tags added: lenny, sid End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#430186: Upgrading to dbus 1.1.1 breaks some gnome-system-tools.
Processing commands for [EMAIL PROTECTED]: reassign 430186 libnet-dbus-perl Bug#430186: Upgrading to dbus 1.1.1 breaks some gnome-system-tools. Bug reassigned from package `gnome-system-tools' to `libnet-dbus-perl'. stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430210: mhc-utils: Uninstallable because postinst fails
On June 23, 2007 at 3:25PM +0200, jeroen (at vrijschrift.org) wrote: Anyway, I'll cleanup mhc-utils.postinst to fix this bug in the next upload. Debugging the postinst, the problem seems to be db_get 'shared/pilot/port' If I install kpilot, which asks the debconf question which port to use, the problem goes away. Thanks for debugging. I disabled the problematic lines just now. Because mhc-utils's Palm Pilot feature is currently broken. See also bug#398459. Thanks, -- Tatsuya Kinoshita pgpTXyyjUCz6i.pgp Description: PGP signature
Bug#430234: ldbl128 transition for alpha, powerpc, sparc, s390
Package: felix Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430237: ldbl128 transition for alpha, powerpc, sparc, s390
Package: ghdl Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430295: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libqd-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430310: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libwine-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430227: ldbl128 transition for alpha, powerpc, sparc, s390
Package: atlas3-headers Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430276: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libmpich-shmem1.0-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430299: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libsmi2-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430317: ldbl128 transition for alpha, powerpc, sparc, s390
Package: nickle Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430269: ldbl128 transition for alpha, powerpc, sparc, s390
Package: liblpsolve55-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430300: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libstk0-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430324: ldbl128 transition for alpha, powerpc, sparc, s390
Package: pnetc Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430286: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libopenexr-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430323: ldbl128 transition for alpha, powerpc, sparc, s390
Package: pike7.6-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430305: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libstlport4.6-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430320: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libwvstreams-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430332: ldbl128 transition for alpha, powerpc, sparc, s390
Package: wx2.6-headers Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430289: klineakconfig always segfaults on D810
Subject: klineakconfig always segfaults D810 Package: klineakconfig Version: 0.9-5 Severity: grave Justification: renders package unusable Hi, I'm using a dell810 and I habe already seen klineakconfig running on this machine but if a try to install klineadconfig from scratch, klineakconfig always crashes. Using gdb, I get this (no debug so not so informative :() Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1232660256 (LWP 16905)] 0xb78af1f2 in KCmdLineArgs::parseAllArgs () from /usr/lib/libkdecore.so.4 (gdb) I have remove *all* the lineak related files and reinstall all of them but the bug is still here. Xavier *** Please type your report below this line *** -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc5-10 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages klineakconfig depends on: ii kdelibs4c2a 4:3.5.7.dfsg.1-1 core libraries and binaries for al ii libc6 2.5-11 GNU C Library: Shared libraries ii libgcc1 1:4.2-20070609-1 GCC support library ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii liblineak-0.9-0 1:0.9-3 LinEAK development files ii libpng12-0 1.2.15~beta5-2 PNG library - runtime
Bug#430238: ldbl128 transition for alpha, powerpc, sparc, s390
Package: fftw3-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430235: ldbl128 transition for alpha, powerpc, sparc, s390
Package: fftw-docs Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430315: ldbl128 transition for alpha, powerpc, sparc, s390
Package: llvm-cfe Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430298: ldbl128 transition for alpha, powerpc, sparc, s390
Package: librudiments-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430331: ldbl128 transition for alpha, powerpc, sparc, s390
Package: wireshark-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430252: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libcppunit-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430301: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libstlport5.0-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430319: ldbl128 transition for alpha, powerpc, sparc, s390
Package: pdl Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430329: ldbl128 transition for alpha, powerpc, sparc, s390
Package: tendra Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430279: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libniftiio0-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430313: ldbl128 transition for alpha, powerpc, sparc, s390
Package: mercury Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430255: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libgoffice-1-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430263: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libhdf5-serial-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430314: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libwww-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430316: ldbl128 transition for alpha, powerpc, sparc, s390
Package: meschach-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430282: ldbl128 transition for alpha, powerpc, sparc, s390
Package: liborbit-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430265: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libicu36-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430333: ldbl128 transition for alpha, powerpc, sparc, s390
Package: wx2.4-headers Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430231: ldbl128 transition for alpha, powerpc, sparc, s390
Package: ecl Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430249: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libdbi-perl Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430306: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libterralib1-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430308: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libuclibc-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430274: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libmpich-mpd1.0-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430261: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libhdf5-lam-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430246: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libbind-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426353: MySQL security bug
tags 426353 + security pending retitle 426353 CVE-2007-2583: DoS in item_cmpfunc.cc (MySQL#27513) fixed 426353 5.0.40 stop An upload for stable-security has been prepared by Sean on May 28 and the Security Team has been reminded on Jun 18. bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: MySQL security bug
Processing commands for [EMAIL PROTECTED]: tags 426353 + security pending Bug#426353: mysql-server-5.0: Please add patch for this bug to stable mysql-5.0 server. http://bugs.mysql.com/bug.php?id=27513 There were no tags set. Tags added: security, pending retitle 426353 CVE-2007-2583: DoS in item_cmpfunc.cc (MySQL#27513) Bug#426353: mysql-server-5.0: Please add patch for this bug to stable mysql-5.0 server. http://bugs.mysql.com/bug.php?id=27513 Changed Bug title to `CVE-2007-2583: DoS in item_cmpfunc.cc (MySQL#27513)' from `mysql-server-5.0: Please add patch for this bug to stable mysql-5.0 server. http://bugs.mysql.com/bug.php?id=27513'. fixed 426353 5.0.40 Bug#426353: CVE-2007-2583: DoS in item_cmpfunc.cc (MySQL#27513) Bug marked as fixed in version 5.0.40. stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430210: marked as done (mhc-utils: Uninstallable because postinst fails)
Your message dated Sat, 23 Jun 2007 13:02:17 + with message-id [EMAIL PROTECTED] and subject line Bug#430210: fixed in mhc 0.25.1+20070620-1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: mhc-utils Version: 0.25.1+20070220-1 Severity: grave Justification: renders package unusable Postinst fails and that makes the packages uninstallable: Unpacking mhc-utils (from .../mhc-utils_0.25.1+20070220-1_amd64.deb) ... Setting up mhc-utils (0.25.1+20070220-1) ... dpkg: error processing mhc-utils (--configure): subprocess post-installation script returned error exit status 10 Errors were encountered while processing: mhc-utils E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mhc-utils depends on: ii libc6 2.5-9 GNU C Library: Shared libraries ii libgtk2-ruby 0.15.0-1.1 GTK+ bindings for the Ruby languag ii libpisock90.12.2-9 library for communicating with a P ii libruby1.81.8.6-1+b1 Libraries necessary to run Ruby 1. ii ruby1.8 1.8.6-1+b1 Interpreter of object-oriented scr Versions of packages mhc-utils recommends: ii mhc0.25.1+20070220-1 Message Harmonized Calendaring sys -- no debconf information ---End Message--- ---BeginMessage--- Source: mhc Source-Version: 0.25.1+20070620-1 We believe that the bug you reported is fixed in the latest version of mhc, which is due to be installed in the Debian FTP archive: mhc-utils_0.25.1+20070620-1_i386.deb to pool/main/m/mhc/mhc-utils_0.25.1+20070620-1_i386.deb mhc_0.25.1+20070620-1.diff.gz to pool/main/m/mhc/mhc_0.25.1+20070620-1.diff.gz mhc_0.25.1+20070620-1.dsc to pool/main/m/mhc/mhc_0.25.1+20070620-1.dsc mhc_0.25.1+20070620-1_all.deb to pool/main/m/mhc/mhc_0.25.1+20070620-1_all.deb mhc_0.25.1+20070620.orig.tar.gz to pool/main/m/mhc/mhc_0.25.1+20070620.orig.tar.gz A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Tatsuya Kinoshita [EMAIL PROTECTED] (supplier of updated mhc package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Jun 2007 21:29:27 +0900 Source: mhc Binary: mhc-utils mhc Architecture: source all i386 Version: 0.25.1+20070620-1 Distribution: unstable Urgency: low Maintainer: Tatsuya Kinoshita [EMAIL PROTECTED] Changed-By: Tatsuya Kinoshita [EMAIL PROTECTED] Description: mhc- Message Harmonized Calendaring system mhc-utils - Message Harmonized Calendaring system utilities Closes: 430210 Changes: mhc (0.25.1+20070620-1) unstable; urgency=low . * New upstream release. (development snapshot, downloaded from `http://www.quickhack.net/mhc/arc/mhc-current-snap20070620.tar.gz') * debian/mhc-utils.postinst: Disable libpisock8 stuff. (closes: #430210) * debian/control: - Prefer emacs to emacs21. - Add emacs22 to Depends. - Remove emacs-snapshot from Depends. Files: 6546d3413dfa494c9bfe2b41d0abf4f5 661 misc optional mhc_0.25.1+20070620-1.dsc c4dd9441ca207d3bc6ac52a2153dbece 238561 misc optional mhc_0.25.1+20070620.orig.tar.gz bb89df8ab68331ae9867e95eedda85c0 21576 misc optional mhc_0.25.1+20070620-1.diff.gz 0fb726ec0afaf2b486b38340c1a0c8d4 169548 misc optional mhc_0.25.1+20070620-1_all.deb c065e7f51212100bb71e81ef4a28085e 106148 misc optional mhc-utils_0.25.1+20070620-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGfRI8gV4LPvpMUpgRAjBMAKDXMOHyg9YitjVPfS+JNprTPu9Z1QCg2C3d Hi8u96os13MUxtH08mflr0k= =iDM5 -END PGP SIGNATURE- ---End Message---
Bug#430217: Fails to build xdpyinfo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 xdriinfo Sorry the wrong one. It is xdriinfo which does not build. And I also find the reason. The symlink /usr/lib/libGL.so is needed but not on my system. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRn0da5+OKpjRpO3lAQLsuwgAj521dc5qnHzg7j9gfS1rQuFtSItrmiHC 1AOZG3/yTS0RtIMQRqdpvKRHXpjWFIGH4C6DBjtieO/LN842YlFUn1ZpjwZvAdaC ejjdAk5bKcaYXw6NOyB1j7hafGIIuJlsxt0cm4W/0ozQ+vVrVshwhm7B15hgJl+M UhQu3aMiZyhKVq/K0Mdl9pqDEr3vHYEK/LR7JKbDoPfvC5RjV2eP8ItmGB/fTFMT 5GfS6AXUjNc4mZvPfD6Xn9scmDQfcFpfSFzt570D1EQbjeQ0Iio9phrGUplg4nE7 YDYRWoDc/Qp3rdUycwsony9mEUBq8njZooZLTRl0n+oF2ygReiKkDA== =0wTQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430302: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libstlport5.1-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430267: ldbl128 transition for alpha, powerpc, sparc, s390
Package: liblo0-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430239: ldbl128 transition for alpha, powerpc, sparc, s390
Package: harbour Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417539: marked as done (tinymux: Buffer overflow in fun_ladd of funmath.cpp with security implications.)
Your message dated Sat, 23 Jun 2007 14:02:05 + with message-id [EMAIL PROTECTED] and subject line Bug#417539: fixed in tinymux 2.4.3.31-1.1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: tinymux Version: 2.4.3.31-1 Severity: grave Tags: security Justification: user security hole http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1655 Overview: Buffer overflow in the fun_ladd function in funmath.cpp in TinyMUX before 20070126 might allow remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via unspecified vectors related to lists of numbers. Fix exists in upstream release. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages tinymux depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 tinymux recommends no packages. -- no debconf information ---End Message--- ---BeginMessage--- Source: tinymux Source-Version: 2.4.3.31-1.1 We believe that the bug you reported is fixed in the latest version of tinymux, which is due to be installed in the Debian FTP archive: tinymux_2.4.3.31-1.1.diff.gz to pool/main/t/tinymux/tinymux_2.4.3.31-1.1.diff.gz tinymux_2.4.3.31-1.1.dsc to pool/main/t/tinymux/tinymux_2.4.3.31-1.1.dsc tinymux_2.4.3.31-1.1_ia64.deb to pool/main/t/tinymux/tinymux_2.4.3.31-1.1_ia64.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Barth [EMAIL PROTECTED] (supplier of updated tinymux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Jun 2007 13:49:59 + Source: tinymux Binary: tinymux Architecture: source ia64 Version: 2.4.3.31-1.1 Distribution: unstable Urgency: medium Maintainer: Ervin Hearn III [EMAIL PROTECTED] Changed-By: Andreas Barth [EMAIL PROTECTED] Description: tinymux- text-based multi-user virtual world server Closes: 417539 Changes: tinymux (2.4.3.31-1.1) unstable; urgency=medium . * Non-maintainer upload. * Fix buffer overflow CVE-2007-1655. Closes: #417539 Files: b615311fbc119e4658c0f3ba68dbc9f9 603 games optional tinymux_2.4.3.31-1.1.dsc d453d5140c622261b781fb374fa2a144 25710 games optional tinymux_2.4.3.31-1.1.diff.gz c28d596b93c199bddb9cb00baacdd5e7 790312 games optional tinymux_2.4.3.31-1.1_ia64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGfScomdOZoew2oYURAj8DAKCOagsJzohsjgdjAd1O/57Fx8l+hACfU6cB n+EAkTOW9kMieE273+04TME= =6iSw -END PGP SIGNATURE- ---End Message---
Bug#430186: Upgrading to dbus 1.1.1 breaks some gnome-system-tools.
reassign 430186 libnet-dbus-perl stop On Sat, Jun 23, 2007 at 11:19:40AM +0200, Loïc Minier wrote: tags 430186 + confirmed stop With current sid, I get: (users-admin:20537): Liboobs-WARNING **: There was an unknown error communicating with the backends: Message did not receive a reply (timeout by message bus) (users-admin:20537): Liboobs-WARNING **: There was an unknown error communicating with the backends: Message did not receive a reply (timeout by message bus) I don't see why the DBus version changes anything. I did some debugging. In the new DBus release the assert for dbus_message_iter_open_container was made somewhat more strict. Which means that some incorrect calls now hit an assert while they previously were incorrectly allowed. libnet-dbus-perl calls dbus_message_iter_open_container with invalid arguments in several places, but got away with it untill now.. Sjoerd -- Philosophy will clip an angel's wings. -- John Keats
Bug#430210: mhc-utils: Uninstallable because postinst fails
At Sat, 23 Jun 2007 21:09:55 +0900 (JST), Tatsuya Kinoshita wrote: On June 23, 2007 at 1:39PM +0200, jeroen (at dekkers.cx) wrote: Postinst fails and that makes the packages uninstallable: Unpacking mhc-utils (from .../mhc-utils_0.25.1+20070220-1_amd64.deb) ... Setting up mhc-utils (0.25.1+20070220-1) ... dpkg: error processing mhc-utils (--configure): subprocess post-installation script returned error exit status 10 Errors were encountered while processing: mhc-utils E: Sub-process /usr/bin/dpkg returned an error code (1) Hmm, I cannot reproduce this bug. mhc-utils is installable on my environment (sid, i386). Anyway, I'll cleanup mhc-utils.postinst to fix this bug in the next upload. Debugging the postinst, the problem seems to be db_get 'shared/pilot/port' If I install kpilot, which asks the debconf question which port to use, the problem goes away. Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430334: ldbl128 transition for alpha, powerpc, sparc, s390
Package: xemacs21-bin Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430232: ldbl128 transition for alpha, powerpc, sparc, s390
Package: elks-libc Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430318: ldbl128 transition for alpha, powerpc, sparc, s390
Package: llvm Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430233: ldbl128 transition for alpha, powerpc, sparc, s390
Package: etl-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430268: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libloki-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430330: ldbl128 transition for alpha, powerpc, sparc, s390
Package: tcc Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430270: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libitpp-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430296: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libqhull-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430285: ldbl128 transition for alpha, powerpc, sparc, s390
Package: liborsa0-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430312: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libwww-ssl-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430327: ldbl128 transition for alpha, powerpc, sparc, s390
Package: sparsehash Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430278: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libnewmat10-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430228: ldbl128 transition for alpha, powerpc, sparc, s390
Package: cmix Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430271: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libmagick9-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430245: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libalps-light1-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430294: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libpqxx-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430253: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libgmp3-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428782: marked as done (nvidia-glx-legacy-96xx: uninstallable due to missing nvidia-kernel-legacy-96xx-1.0.9631 dependency)
Your message dated Sat, 23 Jun 2007 09:56:29 -0400 with message-id [EMAIL PROTECTED] and subject line Invalid has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: nvidia-glx-legacy-96xx Severity: serious Justification: 2 nvidia-kernel-legacy-96xx-1.0.9631 is currently not available in the archive, and since nvidia-glx-legacy-96xx depends on it, the package is not installable. thanks for the hard work. mike -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nvidia-glx-legacy-96xx depends on: ii libc6 2.5-9+b1 GNU C Library: Shared libraries ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar pn nvidia-kernel-legacy-96xx-1.0 none (no description available) ii x11-common1:7.2-3X Window System (X.Org) infrastruc nvidia-glx-legacy-96xx recommends no packages. ---End Message--- ---BeginMessage--- The fact that there are no prebuilt nvidia 96xx LKM packages does not mean that Debian decided not to distribute some...as shown by Randall's message. that is not the point i have been making. you continue to misunderstand. the nvidia-kernel-legacy-96xx-$(uname -r)-* packages are still not available in the unstable archive. hence, this bug cannot be considered done. You don't understand. The reason I'm closing this report is not that the prebuilt nvidia 96xx packages are available in sid, but that your report is invalid. There is no bug as your report describes. If you'd decide to reopen this report, you should defend its validity. ---End Message---
Bug#430240: ldbl128 transition for alpha, powerpc, sparc, s390
Package: kmymoney2 Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430307: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libtao-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430275: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libmpich1.0-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430243: ldbl128 transition for alpha, powerpc, sparc, s390
Package: erlang-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430236: ldbl128 transition for alpha, powerpc, sparc, s390
Package: gclcvs Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430304: ldbl128 transition for alpha, powerpc, sparc, s390
Package: libsscm-dev Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 421983
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.5 tags 421983 + lenny sid Bug#421983: FTBFS: /usr/bin/ld: cannot find -lrsvg-2 There were no tags set. Tags added: lenny, sid End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 420900
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.5 tags 420900 + lenny sid Bug#420900: FTBFS: stats.c:160: error: 'CLK_TCK' undeclared (first use in this function) There were no tags set. Tags added: lenny, sid End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430333: marked as done (ldbl128 transition for alpha, powerpc, sparc, s390)
Your message dated Sun, 24 Jun 2007 00:54:32 +0930 with message-id [EMAIL PROTECTED] and subject line Bug#430333: ldbl128 transition for alpha, powerpc, sparc, s390 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: wx2.4-headers Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. ---End Message--- ---BeginMessage--- The long double type is only used for native Mac(OS) builds in this source, so I think we can safely call this a false positive. Ron On Sat, Jun 23, 2007 at 03:49:12PM +0200, Matthias Klose wrote: Package: wx2.4-headers Severity: serious User: [EMAIL PROTECTED] Usertags: goal-ldbl128 Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' data type did change from a 64bit representation to a 128bit representation on alpha, powerpc, sparc, s390. To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. Both libc and libstdc++ do not need to be renamed, because they support both representations. We rename the library packages on all architectures to avoid name mismatches between architectures (you can avoid the renaming by supporting both datatype representations in the library as done in glibc and libstdc++, but unless a library is prepared for that, it does not seem to be worth the effort). It is suggested to rename a package libfoo1 to libfoo1ldbl; please wait with the renaming if the package depends on another library package which needs renaming. This package has been indentified as one with header files in /usr/include matching 'long *double'. Please close this bug report if it is a false positive, or rename the package accordingly. ---End Message---
