James Troup wrote:
Hi,
Are you alive? I think Santiago is having evil ideas about hijacking
packages.
--
James
I _am_ alive...just barely. Unfortunately, it looks like a) most of my
mail for the past month ended up in the bit bucket, and b) I'm no longer
going to have time to
John Goerzen wrote:
OK, then I suspect the policy is at fault. (BTW, I checked it out and
I did find dc and bc on SunOS -- I had not known these programs were
on other OSs.)
By the current definition of Important:
[snip]
* lilo should not be there because lilo is not part of UNIX
Now
Hamish Moffatt wrote:
On Jun 22, Galen Hazelwood wrote
Hamish Moffatt wrote:
Nope. What happens is most (single-cpu) developers upload the source
and binaries for one architecture. Then helpful and nice developers who
own other machines upload binaries for their cpu, built from
Thomas Koenig wrote:
An attractive alternative would be RIPEMD-160. SHA-1, another
alternative, has the main problem that its design parameters are secret.
Source code for RIPEMD-160 is avialiable, and the algorithm is in the
public domain. For more information, you can check out
Mathieu Guillaume wrote:
Package: cpp 2.7.2.2-5
This is the same kind of bug that was reported as #10753
(update-alternative).
When I try to upgrade to this version, I get an error related to
cross-device links (/lib/cpp is a symlink to /usr/bin/cpp, which is
mounted on a different
Mark Eichin wrote:
Hmm. While there are *particular* problems doing 32-64 bit cross
compilation, doing any 32-32 compilation is probably *quite* solid.
(In particular, compilers targeting the 68k are probably *better* than
the x86 native compiler -- because we've [we==Cygnus] actually had a
Mark Baker wrote:
g77: needs gcc source code to build
Yes, but the alternative is for the source package to be much bigger than it
needs to be. A better solution would be to merge the source packages.
Perhaps you mean something else by the word merge, but, again, merged
sources
Michael Meskes wrote:
Does this mean I could upload all architecture version for my packages?
If so yes, I think it's useful.
Michael
Well, I personally distrust cross-compilers...at least gcc cross
compilers. I know that at least one crossover (i386-alpha) has been
known to produce
Colin Plumb wrote:
Package: info, tin
Version: 3.9-5, 970613-2
Both of these packages depend on libc6 and ncurses3.4.
I'm tracking hamm very closely, and have seen no sign of ncurses3.4.
I haven't seen an ncurses version more recent than 1.9.9g, actually.
Is there any particular
Hamish Moffatt wrote:
It occurred to
me that since most of the Debian packages
are also available for m68k and also
Sparc and Alpha now, the develops are probably
using cross-compilation, rather than actually
owning all these machines.
Nope. What happens
Lars Wirzenius wrote:
fileutils: calls msgfmt with wrong arguments
No, you have the wrong msgfmt. :) {file,shell,text}utils require the
gettext package to be installed in order to build properly. This
package contains xmsgfmt, which formats text versions of translation
files into
I've finally released an ncurses3.0 package for hamm, with an -altdev
package for those of us on mixed-library machines. I've put it into my
home directory on master, hopefully to be joined RSN by ncurses3.4 for
libc6.
As soon as both of them are up and (seemingly) running, I'll put them in
Andreas Jellinghaus wrote:
who is working on ncurses ?
I was about to start. :)
i made ncurses 4.1 for local use and could upload it right now (ok, it's
revoked). it would only take me a few hours to downgrade to the latest
ncurses 1.9.9g IIRC, and a few more to create a altdev package.
Vincent Renardias wrote:
it's good idea, but since ncurses is orphaned this won't help for this
package. Is the libc6 maintainer opposed to maintain ncurses as a libc6
add-on (Or si someone willing to adopt ncurses)?
I'm thinking of adopting ncurses, and might prepare a temporary libc6
Johnie Ingram wrote:
Am I correct in thinking the major players to be synchronized here are
shellutils (who), sysvinit (last), netstd (rsh), login, ppp, procps,
wu-ftpd, and ssh?
Add xbase (xdm) and you've pretty much got it covered.
--Galen
--
TO UNSUBSCRIBE FROM THIS MAILING LIST:
Jason Gunthorpe wrote:
On 1 Jun 1997, Mark Eichin wrote:
I believe libc5.so is LGPL...
I don't. /usr/doc/libc5//copyright doesn't *mention* the LGPL *at
all*, though the libc6 one mentions both.
Yep, the copyright file does not mention the LGPL at all. This seems to me
to be
Rob Browning wrote:
Galen Hazelwood [EMAIL PROTECTED] writes:
I think it also chooses some instructions differently for a 486, and
these choices are also good on the pentium. That's why, when building
binaries for my use, I use -m486 but add flags which turn off the
alignment
Christian Schwarz wrote:
On Thu, 29 May 1997, Galen Hazelwood wrote:
(Don't ask me what the historical reasons are, though. I might start to
whimper...)
Sorry, but I couldn't resist :-) What are the reasons?
I don't know. That's why I whimper...
If we make this policy, we should
Brian White wrote:
I wasn't aware that the Z-machine knowledge had changed in the past
half-dozen years or so. The infocom program handles all the games
I've ever tried with it, so I don't see why it is obsolete.
Oh, it works fine in normal cases. But we now understand certain
obscure v5 and
Raul Miller wrote:
On May 31, Galen Hazelwood wrote
Perhaps. Anybody have any serious arguments? I think the reason we
configure gcc as i486 is so it automatically optimizes for the 486; it's
a good middle ground.
If I remember right, configuring for pentium leaves an executable
Ben Pfaff wrote:
Just butting in on this thread to ask a question. Is there a
de-compiler for Infocom games? Would such a de-compiler produce
readable source code? Just a thought... (I know nothing about the
Infocom game language or the binary format.)
Check out txd in the ztools package.
Guy Maor wrote:
I think the only optimization gcc 2.7.* does for i486 is instruction
alignment. The Pentium has a better fetch unit so doesn't need any
alignment (it never incurs a misfetch penalty) so optimizing for i486
will at least give some code bloat.
I think it also chooses some
Mark Eichin wrote:
yeah, cygwin32.dll is under the GPL. So? It's a DLL, like libc5 and
libc6 are... [the *only* thing I'm aware of that actually uses the
LGPL is libg++; it was as much of an experiment as anything, and I'm
not aware of any not-otherwise-free software taking advantage of
Mark Eichin wrote:
I just brought this up, since it was my understanding that if you
want to write a commercial program (ie. not under the GPL), and
link it against cygwin.dll, you've got to pay Cygnus $$$. Not all
that different than the restrictions on Qt, really.
Two questions:
Michael Alan Dorman wrote:
RMS has stepped in. I can't quite decide if that's likely to foster
resolution or small-arms usage.
Stepped in on whose side?
--Galen
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL
Michael Alan Dorman wrote:
Debian developers:
ESR has, IMHO, decided to start a pissing match about ncurses
development. I have no desire to participate or watch.
My frank recommendation is that we ditch ncurses entirely, go back to
BSD curses and termcap and encourage authors of free
Christian Schwarz wrote:
Next step: GNU's configure utility. I thought that we had agreed on
using
i386-unknown-linux
(and similar for the other architectures), but then I had just discovered
that GCC uses
/usr/lib/gcc-lib/i486-linux/2.7.2.1/
Thomas Koenig wrote:
I just spent an interesting afternoon trying to upgrade a 1.1 system
to 1.3.
First, /var/lib/dpkg/available was corrupted because of some
incorrect values in the Version - field (somehow they had gotten to
the format of 1:1-2 or similar; bug report submitted). I
Gregor Hoffleit wrote:
Include the multi-thread support patch for the Objective-C runtime lib (???)
bo includes gstep-base-0.2.12 and gstep-base-0.2.12 includes a patch file
gcc-2.7.2.1-objc.diff, which therefore should be applied to the gcc in bo
(the patch applies fine to gcc-2.7.2.2).
29 matches
Mail list logo
