Re: GCC 4.1 now the default GCC version for etch

2006-06-17 Thread Falk Hueffner
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Falk Hueffner <[EMAIL PROTECTED]> writes: >> On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: >>> Falk Hueffner <[EMAIL PROTECTED]> writes: >>> > So in summary, if yo

Re: GCC 4.1 now the default GCC version for etch

2006-06-17 Thread Falk Hueffner
On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: > Falk Hueffner <[EMAIL PROTECTED]> writes: > > So in summary, if you don't care about portability to 64-bit windows, > > assuming sizeof(void*) == sizeof(long) is just fine. > > Unless you comp

Re: GCC 4.1 now the default GCC version for etch

2006-06-17 Thread Falk Hueffner
On Fri, Jun 16, 2006 at 07:06:06PM -0500, Ron Johnson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Falk Hueffner wrote: > > On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: > >> long is not appropriate to save pointers, you need to use

Re: GCC 4.1 now the default GCC version for etch

2006-06-17 Thread Falk Hueffner
On Fri, Jun 16, 2006 at 02:39:26PM -0700, Philip Brown wrote: > On Fri, Jun 16, 2006 at 11:15:32PM +0200, Falk Hueffner wrote: > > Henning Makholm wrote: > > > > > Another related bug type that I found lurking in my packages when I > > > investigated the warnings

Re: GCC 4.1 now the default GCC version for etch

2006-06-16 Thread Falk Hueffner
Henning Makholm wrote: > Another related bug type that I found lurking in my packages when I > investigated the warnings in this list, is trying to format a size_t > value with a %u or %d format string, which will break if size_t is 64 > bits (unless the actual number is small and it is the last a

Re: GCC 4.1 now the default GCC version for etch

2006-06-16 Thread Falk Hueffner
On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: > On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote: > > The others are trivially fixable; of these, the one in libavcodec is already > > fixed in CVS. I've committed the rest (they're basically s/int/long/) and am > > forward

Re: glibc built with gcc-4.1 (update)

2006-05-30 Thread Falk Hueffner
Aurelien Jarno <[EMAIL PROTECTED]> writes: > Falk Hueffner a écrit : >> Aurelien Jarno <[EMAIL PROTECTED]> writes: >> >>>On arm, ia64 and alpha the glibc fails to build with gcc-4.1. >> On Alpha the problem is: >> {standard input}: Assembler

Re: glibc built with gcc-4.1 (update)

2006-05-30 Thread Falk Hueffner
Aurelien Jarno <[EMAIL PROTECTED]> writes: > On arm, ia64 and alpha the glibc fails to build with gcc-4.1. On Alpha the problem is: {standard input}: Assembler messages: {standard input}:341: Error: macro requires $at register while noat in effect {standard input}:374: Error: macro requires $at

Re: How to define a release architecture

2005-03-22 Thread Falk Hueffner
Steve Langasek <[EMAIL PROTECTED]> writes: > On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote: >> Matthew Garrett <[EMAIL PROTECTED]> writes: > >> > * the release architecture must be publicly available to buy new > >> > Avoids a situ

Re: How to define a release architecture

2005-03-21 Thread Falk Hueffner
Matthew Garrett <[EMAIL PROTECTED]> writes: > * the release architecture must be publicly available to buy new > > Avoids a situation where Debian is keeping an architecture alive. I don't understand this. What is the problem with Debian is keeping an architecture alive? What problem are you tryi

Re: Does this break binary compatability on 64bit architectures?

2005-02-24 Thread Falk Hueffner
"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes: >> -int mailpop3_retr(mailpop3 * f, uint32_t index, char ** result, >> +int mailpop3_retr(mailpop3 * f, unsigned int index, char ** result, >> size_t * result_len); > > That is, 'uint32_t' was changed to 'unsigned int'. > > Does

Re: hwcap supporting architectures?

2005-01-16 Thread Falk Hueffner
Marcelo E. Magallon writes: > On Sat, Jan 15, 2005 at 10:14:15PM +0900, GOTO Masanori wrote: > > > > occurs when you have for example an ev56 library in lib/ev56, and a > > > ev67 CPU. Then the loader looks in lib/ev67 and then falls back to > > > lib. Since glibc is very carefully undocumented i

Re: Lintian-induced changes in changelog, hardlinks?

2005-01-14 Thread Falk Hueffner
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > Also, eh, I'm not convinced lintian is correct here in complaining, > I'm a bit unsure. Lintian has warned for any hardlinks for a long time, > but is it really bad to have them? Having them across different > directories might cause problems whe

Re: hwcap supporting architectures?

2005-01-13 Thread Falk Hueffner
GOTO Masanori <[EMAIL PROTECTED]> schrieb am 13.01.05 02:01:11: > At Tue, 11 Jan 2005 11:27:28 +0100, > Falk Hueffner wrote: > > Marcelo E. Magallon <[EMAIL PROTECTED]> wrote: > > > IIRC, alpha does not define any hwcaps. > > > > There's a patc

Re: hwcap supporting architectures?

2005-01-11 Thread Falk Hueffner
GOTO Masanori <[EMAIL PROTECTED]> wrote: > Marcelo E. Magallon <[EMAIL PROTECTED]> wrote: >> Mesa upstream uses -mcpu=ev5 -mieee on alpha. Is that ok? Where does >> this belong into? /usr/lib/ev5? > > IIRC, alpha does not define any hwcaps. There's a patch for this, which works fine, but wasn

Re: Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem

2003-07-05 Thread Falk Hueffner
Ralf Treinen <[EMAIL PROTECTED]> writes: > > E2tools is a simple set of GPL'ed utilities to read, write, and > > manipulate files in an ext2/ext3 filesystem. > > please excuse my ignorance - what would be the advantage of these > tools over the core file utilities which use the VFS layer? You do

Re: Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption

2003-06-29 Thread Falk Hueffner
"Benj. Mako Hill" <[EMAIL PROTECTED]> writes: > On Fri, Jun 27, 2003 at 12:32:59AM +0100, Millis Miller wrote: > > Package: wnpp > > Version: N/A; reported 2003-06-27 > > Severity: wishlist > > > > * Package name: email > > I understand that email is the name of the upstream client but I'd >

Re: Dropping/splitting (proper) i386 support

2003-04-27 Thread Falk Hueffner
Nathanael Nerode <[EMAIL PROTECTED]> writes: > Oddly, it looks like GCC doesn't currently ever generate > 486-specific instructions; they are only (currently) of benefit to > assembly programmers. (Hmm... maybe I should see if there's an > enhancement opportunity to GCC there.) I have a patch fl

Re: package pool and big Packages.gz file

2001-01-07 Thread Falk Hueffner
Sam Vilain <[EMAIL PROTECTED]> writes: > On Fri, 5 Jan 2001 19:08:38 +0200 > [EMAIL PROTECTED] (Sami Haahtinen) wrote: > > > Or, can rsync sync binary files? > > hmm.. this sounds like something worth implementing.. > > rsync can, but the problem is with a compressed stream if you insert > or al

Re: Debian Source distributions (was Re: Intent to package pine-src)

1998-05-07 Thread Falk Hueffner
Brederlow <[EMAIL PROTECTED]> writes: > It would be a great idea to have source dependencies. I compile all > sources on my debian mirror and most fail because of missing > files. One then has to search the package and install that before > compiling again. A very simple way to improve in this ar

Re: X and Window Mangers

1998-04-29 Thread Falk Hueffner
opying over the whole .xssession? Maybe a .window-manager? I think that would be useful, since there are many people who insist on a particular window manager, but don't want to change anything else. Falk Hueffner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of &q

Intent to package: ras, qvwm, descent

1998-04-21 Thread Falk Hueffner
Hello, I intend to apply as a maintainer (as soon as I find somebody to scan my passport ;) and package: - ras (http://dspace.dial.pipex.com/nc/) Ras is a small utility that adds m extra files to a set of n files, such that the contents of the n original files can be regenerated from any n of th

Re: bzip2 X

1998-04-20 Thread Falk Hueffner
Michael Alan Dorman <[EMAIL PROTECTED]> writes: > Bdale Garbee <[EMAIL PROTECTED]> writes: > > As maintainer of gzip for Debian, I do not agree that having gzip > > fork a bzip2 when it sees a bzip2 magic number is a good idea. If > > we want to support multiple compression engines, I believe thi

Re: deb + tar + bzip2 suggestion

1998-04-18 Thread Falk Hueffner
Joel Klecker <[EMAIL PROTECTED]> writes: > At 14:16 +0200 1998-04-18, Brederlow wrote: > >I think it would be a good idea to teach tar to unpack bzip2 files via > >the -z option, just as if it would be gzip. Alternativly one could > >teach gzip to use bzip2 for .bz2 archives or teach dpkg to disti

Re: [?] egcs increases C++ binary size dramatically

1998-04-08 Thread Falk Hueffner
On Wed, 8 Apr 1998 01:01:46 +0200, Marcus Brinkmann <[EMAIL PROTECTED]> wrote: >> It's related to the fact that egcs does exception handling - add >> -fno-exceptions to your CFLAGS, and you'll get a shorter binary. > >I think this is not the right way to think of C++ programming. If you don't >use

Re: source packaging format (was Re: Questions about plans for Emacs 20...)

1998-04-08 Thread Falk Hueffner
plans about this in 2.x versions? Falk Hueffner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]