hi, i have build parrot and pugs this weekend from the CPAN tarballs on my
550mhz ppc debian etch system
i used no other upstream sources than CPAN. although there were some
hassles getting the modules all downloaded and install that needed for the perl5
support part, the debian packages provided
On Sun, Feb 25, 2007 at 05:09:00PM +0100, Roman Zippel wrote:
Combining 3 mail replies to one...
> > My question is now:
> > What is the *exact* plan for m68k for Etch and beyond?
> IMO as long as there are few people who have the power to veto m68k out of
> existence, I don't see much further
On Mon, Feb 26, 2007 at 12:02:05PM +1100, Finn Thain wrote:
> I agree completely. I've fought political attempts to downgrade bugs
> before (in gentoo's ppc-macos port. Fortunately, those in power were more
> open to discussion.)
> In Debian, it seems that the political cost of losing an arch is
what i understood from reading about coldfire:
it is 10x faster than 68060 (not fast by today's standards,
but still capable if not unreasonable about demand from it)
it is problematic in some floating point areas
-- not that much faster there (think ppc604*), more in the integer part
-- it do
On Mon, 26 Feb 2007, Brian Morris wrote:
> could someone explain issue with TLS,
>
> ? it is needed because SSL is not up to GNU FSW standards ?
>
> ? the GNU package for TLS does not build without some hidden
> assumed support ? I looked on the GNU download page and it mentions
> it requires one
On Mon, 26 Feb 2007, Brian Morris wrote:
> i believe that handhelds will be the hot product in the next few years.
Perhaps coldfire devices will proliferate. Who knows?
>
> could someone explain issue with TLS,
>
The release after Etch requires glibc 2.4/2.5, which means porting the
Nativ
On Mon, Feb 26, 2007 at 01:39:28AM -0800, Brian Morris wrote:
> realistically, the value of 68k as a teaching tool is high. because of
> its limitations partly. you learn how to make best use of limited resources.
> with new computers you learn the opposite...
I agree. When I was still doing 3D c
On Sun, Feb 25, 2007 at 05:29:02PM +0100, Roman Zippel wrote:
> On Sat, 24 Feb 2007, Wouter Verhelst wrote:
> > At this point, though, I'm still convinced that it's possible to create
> > a port which will work on both coldfire and "classic" m68k; and with a
> > glibc that has TLS support (which we
Hi,
On Mon, 26 Feb 2007, Wouter Verhelst wrote:
> > It's probably not impossible, but I highly question whether it's really
> > desirable. The instructions sets are already quite different
>
> This is not true. The ColdFire V4e instruction set is a near-strict
> subset of the m68k one. The only
Roman Zippel wrote:
> Hi,
>
> On Mon, 26 Feb 2007, Wouter Verhelst wrote:
>
>>> It's probably not impossible, but I highly question whether it's really
>>> desirable. The instructions sets are already quite different
>> This is not true. The ColdFire V4e instruction set is a near-strict
>> subse
On Mon, Feb 26, 2007 at 02:53:52PM +0100, Roman Zippel wrote:
> On Mon, 26 Feb 2007, Wouter Verhelst wrote:
> > > It's probably not impossible, but I highly question whether it's really
> > > desirable. The instructions sets are already quite different
> >
> > This is not true. The ColdFire V4e i
Hi,
James Troup was at FOSDEM this weekend, and we talked a bit about the
m68k situation there, amongst others. My first question was about the
state of our buildd addition requests, and whether it was on purpose or
so that none of them had been granted yet. He basically apologised for
not acting
On Sun, Feb 25, 2007 at 05:09:00PM +0100, Roman Zippel wrote:
> Hi,
>
> On Fri, 23 Feb 2007, Ingo Juergensmann wrote:
>
> > My question is now:
> > What is the *exact* plan for m68k for Etch and beyond?
>
> IMO as long as there are few people who have the power to veto m68k out of
> existence,
On Mon, Feb 26, 2007 at 01:39:28AM -0800, Brian Morris wrote:
> what i understood from reading about coldfire:
>
> it is 10x faster than 68060 (not fast by today's standards,
> but still capable if not unreasonable about demand from it)
>
> it is problematic in some floating point areas
> -- not
Hi,
On Mon, 26 Feb 2007, Wouter Verhelst wrote:
> This is a confusion in wording on my part, I'm afraid. When I say
> "classic m68k", I mean "non-coldfire m68k processors supported by
> Linux", i.e., at least the 68020 :)
Well, you seem to a have broader definition of "near-strict subset" than
On Mon, Feb 26, 2007 at 07:46:32PM +0100, Roman Zippel wrote:
> On Mon, 26 Feb 2007, Wouter Verhelst wrote:
> > If that turns out to be not feasible, we'll then have to decide where to
> > go; the options as I see them at that point are these:
> > * Go with an emulator on an amd64 machine, and hop
On Mon, 26 Feb 2007, Roman Zippel wrote:
> Hi,
>
> On Mon, 26 Feb 2007, Wouter Verhelst wrote:
>
> > > FP is even worse, the fp registers have different sizes, long double
> > > support is different and the fp return value is different.
> >
> > Floating point is not an exact science anyway;
17 matches
Mail list logo
