Re: Help in gcc-4.0.x transition issue
Andreas Tille wrote: /home/tillea/debian-maintain/packages/arb/arb-0.0.20050506/INCLUDE/awt_canvas.hxx:67: error: 'AWT_canvas' has not been declared make[2]: *** [AW_preset.o] Error 1 make[2]: *** Waiting for unfinished jobs I guess it is a really small problem for people with C++ knowledge and thus I hope to get a quick answer here. The question is whether friend class AWT_canvas; is a declaration of class AWT_canvas. People used to think it is, but (now) think it only declares it as a friend. So you need to add class AWT_canvas; at the beginning of the header file. Regards, Martin P.S. Disclaimer: the explanation is from memory only, and the solution is not tested. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: WebSVN of svn.debian.org uses wrong encoding
Frans Pop wrote: Who cares what default it sets or not sets? The point is that it has no way to determine the correct encoding for files in the svn repo. That is not true. For file that have the svn:mime-type property, it might be possible. For example, if the mime-type indicates it is XML, then you can find the encoding from the contents of the file. In this case, this would have helped. There are repeated discussions whether a svn:charset property should be introduced. I think this discussion always ended with the observation that the mime-type property has values that are really media-types, and that media-types can have parameters, such as the charset parameter. If people really want to get proper web-rendering of Subversion repositories, they should start using these properties; then websvn should start dealing with them in a more convenient way. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-xlib 0.12-5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 20 Aug 2005 17:25:20 +0200 Source: python-xlib Binary: python2.3-xlib python2.4-xlib python-xlib python-xlib-doc Architecture: source all Version: 0.12-5 Distribution: unstable Urgency: low Maintainer: Martin v. Löwis [EMAIL PROTECTED] Changed-By: Martin v. Löwis [EMAIL PROTECTED] Description: python-xlib - Interface for Python to the X11 Protocol (dummy package) python-xlib-doc - Documentation for the Python interface to the X11 Protocol python2.3-xlib - Interface for Python to the X11 Protocol (for Python2.3) python2.4-xlib - Interface for Python to the X11 Protocol (for Python2.4) Closes: 196387 249071 254793 292560 Changes: python-xlib (0.12-5) unstable; urgency=low . * New maintainer (closes: #254793) * Build for Python 2.4 (closes: #292560) * Fall back to unix:0 for localhost:0, modelling what Xlib does and sshd requires (closes: #249071) * Import socket in protocols/display.py (closes: #196387) * Remove python2.1-xlib and python2.2-xlib, as Python 2.1 and 2.2 are going to be removed in the near future. * Move to DH_COMPAT=4, write it to debian/compat. * Recommend info as a concrete alternative to info-browser. * Update build process: remove build-stamp target, use debhelper where possible, remove unnecessary dh commands. * Add watch file. * Add dirinfo into texi sources, regenerate info file into separate directory. * Let python2.[34] suggest python-xlib-doc. Files: 01a8fb5c88fd4dba83ef5a36e735963d 712 python extra python-xlib_0.12-5.dsc 89692d5857c3cb96817d36079f286833 3665 python extra python-xlib_0.12-5.diff.gz 5cf776635edebb0961a73492e3c38c78 3110 python extra python-xlib_0.12-5_all.deb 138bd74a88be9d5f292fe7e7f81d5f19 69560 python extra python2.3-xlib_0.12-5_all.deb 82ad91c98c8645d9bc219be70124577d 69562 python extra python2.4-xlib_0.12-5_all.deb 462249074046baa4cb77c96fdd6406dd 47720 doc extra python-xlib-doc_0.12-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: GnuPG key at http://thomas.viehmann.net/ iD8DBQFDB4zpriZpaaIa1PkRAgjVAKDdUFD2QjaSX8vtj/MkMHo2xgJCdQCfWwn7 6ybJs8YoXiQM1+hGskCfHHo= =5zAB -END PGP SIGNATURE- Accepted: python-xlib-doc_0.12-5_all.deb to pool/main/p/python-xlib/python-xlib-doc_0.12-5_all.deb python-xlib_0.12-5.diff.gz to pool/main/p/python-xlib/python-xlib_0.12-5.diff.gz python-xlib_0.12-5.dsc to pool/main/p/python-xlib/python-xlib_0.12-5.dsc python-xlib_0.12-5_all.deb to pool/main/p/python-xlib/python-xlib_0.12-5_all.deb python2.3-xlib_0.12-5_all.deb to pool/main/p/python-xlib/python2.3-xlib_0.12-5_all.deb python2.4-xlib_0.12-5_all.deb to pool/main/p/python-xlib/python2.4-xlib_0.12-5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python's gettext.gettext broken, use gettext.lgettext
Joe Wreschnig wrote: Which installs ugettext as '_' function into the __builtin__ namespace. That makes _ return Python 'unicode' objects, which is what programs should be using internally anyway. This is harder if you're trying to localize a module since then you don't want to screw with __builtin__ It is also useless for the issues at hand: since linda and apt-listchanges apparently use local strings, giving them Unicode strings would break them. So Junichi's change looks right to me. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
Brian Nelson wrote: OK, very well then, I'll undo the GCC 4 transition for libaspell15. Isn't there still a binary-compatibility issue here? I thought that in an application, there must only be one version of libstdc++, directly or indirectly. Otherwise, during runtime, symbols may resolve from the wrong libstdc++, causing crashes. So if libaspell is linked with libstdc++.so.6, and some application links to both libaspell (through the C API), and libstdc++.so.5 (because it is a C++ application), this application may crash, as it might pick up symbol definitions from libstdc++.so.6 - or libaspell might crash as it picks up some symbols from libstdc++.so.5, and some from libstdc++.so.6. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to Avoid GPL Issue
G. C. wrote: Is there any approach that we can avoid publicizing the third party code while porting to Linux? Do we need to write some shim layer code in Linux kernel to interface the third party code? How can we do that? Is there any document or samples? In general, this is not possible. It is also intentional: One primary goal of the GPL is to require derived work to be published, so it would be quite unfortunate if you could work around this with dirty tricks. The only way to avoid publishing the source is to avoid distributing the binary. You only have to offer the source whoever you provide the binaries. Regards, Martin
Re: Bug#198158: architecture i386 isn't i386 anymore
Marcelo E. Magallon wrote: The patch has been already written: http://lwn.net/Articles/8634/ I'm sure theere's a better link, but that's the best I could extract out of google without resorting to bribery :-) This patch is insufficient. It does not implement xaddl. Regards, Martin
Re: Bug#198158: architecture i386 isn't i386 anymore
John Goerzen wrote:
Nobody has even explained WHY we have this issue. The summary posted on the
bug report just said that there is a problem with atomicity.h, not what the
problem is or why it exists.
Just look at the file for yourself. It is easy enough to see: it uses
inline assembly that is only available on i486:
static inline _Atomic_word
__attribute__ ((__unused__))
__exchange_and_add (volatile _Atomic_word *__mem, int __val)
{
register _Atomic_word __result;
__asm__ __volatile__ (lock; xaddl %0,%2
: =r (__result)
: 0 (__val), m (*__mem)
: memory);
return __result;
}
In particular, the lock prefix is not available on i386. Since this is
an inline function, this code is inserted into any C++ binary, so you
can't change its implementation by replacing the library.
In g++ 3.2, this code was distributed as i386, and nobody noticed that
it doesn't work on i386 for quite some time. In gcc 3.3, an
implementation is provided that works on i386, and this implementation
here is declared i486. Unfortunately, the two implementations are not
binary compatible. Debian has to pick one of these, and it needs to pick
the i486 version for compatibility with other Linux distributions (which
either ship with gcc 3.2 today, or target i586+ only, anyway).
Regards,
Martin
Bug#198158: architecture i386 isn't i386 anymore
John Goerzen wrote: As I say this, I'm sure people can say the same about i486 and even i386 machines. Why exactly do we need to remove this support? Read the bug report with the number you put in your Subject. Regards, Martin
Re: Bug#198158: architecture i386 isn't i386 anymore
John Goerzen wrote: While we're at it, I fail to see the logic of removing support for i386 while we still support m68k. Because there is a bug that only applies to i386 (see the subject). I wish everybody would focus on fixing this specific bug. There may be many good or bad things that can be said about dropping architecture support. This is not what this bug is about: we need to fix a real problem here (C++ ABI compatibility with other Linux distributions). The discussion is now about *how* to fix this bug: 1. just bump minimum supported i386-family processor to i486 2. like 1, but bump to some other processor. this is not strictly needed to fix the bug, but it might be a good idea for other reasons. Dropping other architectures to fix this bug is probably not a good idea, as it won't fix the bug. 3. bump the supported processor, and rename the port 4. like 3, and also add an i386 distribution which does not support C++ at all 5. like 4, but support C++ in a way incompatible with other Linux distributions in the i386 distribution. There are probably more options, but anybody proposing them, or speaking in favour or against one of these options should ask herself whether the message really helps in resolving this bug. Regards, Martin
Re: i386 compatibility libstdc++
Morgon Kanter wrote: Not starting a flamewar here, but in all honesty, who is going to try to use KDE on a 386 anyway? Actually, while we are on that, who is even going to try to use X at all on a 386? Probably nobody will. IMO, it is the worse that the KDE binaries have to be built for i386 compatibility (as the Debian package will have i386 in its name) Regards, Martin
Re: i386 compatibility libstdc++
Andreas Metzler wrote: Does anybody know how/if other Distributions reacted to this issue? Suse, Redhat et.al. afaik have been using gcc-3.x for more than one release. They just don't support i386 anymore. http://www.suse.de/en/private/products/suse_linux/i386/system_requirements.html http://www.redhat.com/software/linux/technical/ You got to have a Pentium+ for these distributions. This is quite reasonable, IMO: People with older hardware can use older versions of these distributions (which they are running probably already, anyway). Regards, Martin
Re: i386 compatibility libstdc++
Lars Wirzenius wrote: So using a 386 as a router and firewall, which it is perfectly capable of hardwarewise Is that really the case? a) Is anybody actually doing this, today? b) Do you then have 10MB or 100MB ethernet in that computer? Can you even put a 100MB ethernet card into the computer? Does it have PCI? I really don't recall the answers to these questions, since it is such a long time that I have last seen a real 386 machine. If there is enough userbase for an i386 distribution, I wouldn't mind if an i386 port was maintained separately. However, I really think it would be a good thing if Linux could, in general, assume 486+ (or perhaps even Pentium+). Regards, Martin
Re: i386 compatibility libstdc++
Matthias Urlichs wrote: Hmm. Did anybody measure the performance increase in a typical userspace-CPU-intensive program when built with i586-only options (as opposed to optimize for i586+ but generate compatible code)? In the current issue, it is not that much a question of performance, but of correctness: the two versions of libstdc++ aren't mutually binary-compatible, so Debian needs to decide whether to support i386 or compatibility with other distributions (and thus likely upcoming jdks etc) - you can't have both. Regards, Martin
Re: [Testing] Why isn't a52dec updating
- Original Message - From: Mikael Hedin [EMAIL PROTECTED] Newsgroups: linux.debian.devel Sent: Sunday, December 08, 2002 11:00 PM Subject: [Testing] Why isn't a52dec updating I see that the testing scripts are running again. Now I wonder why a52dec isn't going in. In update_output.txt I find trying: a52dec skipped: a52dec (1014+21) got: 4+0: a-4 * alpha: ogle, ogle-gui which I read as if the new a52dec entered testing, ogle would be uninstallable. The old ogle (now in testing) depends on liba52-0.7.3, from the source a52dec now in testing. The new ogle depends on liba52-0.7.4, produced by the new a52dec source. I think the culprit is ogle-gui. That is uninstallable as it depends on glibc 2.3.1. Regards, Martin
