On Mon, Apr 28, 2014 at 9:06 PM, Axel Beckert a...@debian.org wrote:
Hi,
Sébastien Bernard wrote:
I have no clue why is it marked oldkernel something related to the buildd ?
The debian.org sparc machines do not work reliably with recent kernels.
That is not sustainable.
Not only them.
Le 26/04/2014 22:59, Julien Cristau a écrit :
On Fri, Apr 18, 2014 at 10:44:16 +0200, Sébastien Bernard wrote:
No, that is not accurate. The main reason is that there are a number
of issues with the sparc port currently that are not being addressed
because apparently nobody is interested
The main problem is that the 2 new buildd are Niagara machines which are
not really stable. It left only 2 buildd which seems to be quit old and
slow.
On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding
the gcc package 3 times - 8hours build - without any issue).
No, that is not accurate. The main reason is that there are a number of
issues with the sparc port currently that are not being addressed
because apparently nobody is interested enough in the sparc port to fix
the issues.
OK, what are the major issues and the bug # assigned to them? I'd
Le 28/04/2014 16:12, Patrick Baggett a écrit :
The main problem is that the 2 new buildd are Niagara machines
which are not really stable. It left only 2 buildd which seems to
be quit old and slow.
On my V240, the 3.13 kernel seems to be rock solid (I've been
rebuilding
Hi,
Sébastien Bernard wrote:
I have no clue why is it marked oldkernel something related to the buildd ?
The debian.org sparc machines do not work reliably with recent kernels.
That is not sustainable.
Not only them. All my Sparcs run Squeeze kernels, too, because neither
Wheezy (3.2) nor
On Fri, Apr 18, 2014 at 10:44:16 +0200, Sébastien Bernard wrote:
Le 18/04/2014 06:56, Joost van Baal-Ilić a écrit :
I'd guess skilled hacker time is more needed than hardware. Reading
https://release.debian.org/jessie/arch_qualify.html , it seems major
blocking issues are: Using gcc-4.6 as
Le 20/04/2014 18:26, Patrick Baggett a écrit :
Also, a lot of the messages about removing v8 support or upstream
dropping sparc32 is confusing. SPARCv8, sometimes called sparc32
(more specifically, 32-bit SPARCv8 ISA that predates the 64-bit ISA,
SPARCv9) is used by just /one/ CPU that is
On Fri, Apr 18, 2014 at 6:11 PM, Sébastien Bernard sbern...@nerim.netwrote:
Doh, beat me to it by a minute. Yeah, you see what I mean. :)
It would be platform suicide to drop 32-bit code generation. Like many
RISC architectures, switching to 64-bit is only done for apps that need it,
Because GCC maintainers have been saying for years, that they are
unwilling to support the weird use case of Debian sparc port, which has
64-bit kernel but 32-bit userspace. I can find discussions about it going
back as far as 2009:
Because GCC maintainers have been saying for years, that they are
unwilling to support the weird use case of Debian sparc port, which has
64-bit kernel but 32-bit userspace. I can find discussions about it going
back as far as 2009:
Also, a lot of the messages about removing v8 support or
I really don't understand why this 32-bit gone myth is happening. It was
poor wording at least. Debian doesn't even support the ancient 32-bit sparc
CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs even when running
in 32-bit code, it's like x32 ABI in x86 land.
SPARCv7, SPARCv8 = old
Le 18/04/2014 14:16, Patrick Baggett a écrit :
I really don't understand why this 32-bit gone myth is happening. It
was poor wording at least. Debian doesn't even support the ancient
32-bit sparc CPUs. Modern SPARC ABIs (post 1997) require 64-bit CPUs
even when running in 32-bit code, it's like
Yeah, I understand why you would believe that. I'm not blaming you, I just
want to let everyone know the sentence 32-bit code generation as we use it
is no longer supported upstream is incorrect. You can see on the GCC 4.7
[1] and 4.8 [2] changes list that removing any SPARC code generation
I don't understand, there is no warning of abi or architecture deprecation
in the release notes of gcc, neither 4.7 nor 4.8.
Maybe they have information I don't, but I doubt it. I'll dig in the gcc
mailing list to see if I can find something related.
Sébastien
Doh, beat me to it by a
Doh, beat me to it by a minute. Yeah, you see what I mean. :)
It would be platform suicide to drop 32-bit code generation. Like many
RISC architectures, switching to 64-bit is only done for apps that
need it, because it is not free and will not, in general, make apps
faster. Anyone who has
Reading the 2 or 3 warning from from debian-devel-announce,
I'm afraid that the sparc architecture is going legacy the same way that
it did for the hppa.
What could it be done to keep this architecture as a first class citizen ?
If I understood correctly, the debian port of debian is on watch
On Fri, Apr 18, 2014 at 02:02:31AM +0200, Sébastien Bernard wrote:
Reading the 2 or 3 warning from from debian-devel-announce,
I'm afraid that the sparc architecture is going legacy the same way
that it did for the hppa.
What could it be done to keep this architecture as a first class citizen
Hi,
sorry for my absence during the past week. My girlfriend and I got a
small baby boy on Wednesday which mixed up my timetable. I guess
that's a usual feature of children that they mix up your life ;-)
First of all a big thankyou to Steve Dunham and Eric Delaunay for
making the Sparc release
On Mon, 8 Mar 1999, Christian Meder wrote:
sorry for my absence during the past week. My girlfriend and I got a
small baby boy on Wednesday which mixed up my timetable. I guess
that's a usual feature of children that they mix up your life ;-)
:-) Congratulations on becoming a dad.
--
Steve
I just have to say I am extremely impressed at the speed that Chris is
pumping out the sparc binary packages.
Question, if the sparc release is now aiming at making slink shouldn't
there be a split for slink/potato? This might avoid any confusion on what
distribution the binaries are based on.
Derrick J Brashear writes:
I've been meaning to have a look at it, I just haven't had the time yet.
The repeat delay does seem rather short (I counted about 0.2 s), and
as far as I can tell it's kernel related (though, as I said, I haven't
really had the time to look at it yet).
One question presetns itself. Versions. Do we add a non-maintainer
version bump? What about if absolutely no change was made? (libungif, for
example, I recompiled as a no-brainer).
As I have understood it, when doing a no-brainer, thus making a
package that didn't needed any editing from
Jules == Jules Bean [EMAIL PROTECTED] writes:
[snip]
Jules in itself, but key to compiling some other things) and this
Jules ldd bug seems annoying, possibly serious.
I saw your post about ldd but have never seen it mis-behave so I
didn't comment.
BTW, I've also never had any problems
On 21 Jul 1998, Stephen Zander wrote:
Jules == Jules Bean [EMAIL PROTECTED] writes:
[snip]
Jules in itself, but key to compiling some other things) and this
Jules ldd bug seems annoying, possibly serious.
I saw your post about ldd but have never seen it mis-behave so I
didn't
On Wed, 22 Jul 1998, Jules Bean wrote:
On 21 Jul 1998, Stephen Zander wrote:
Jules == Jules Bean [EMAIL PROTECTED] writes:
[snip]
Jules in itself, but key to compiling some other things) and this
Jules ldd bug seems annoying, possibly serious.
I saw your post about ldd
Jules == Jules Bean [EMAIL PROTECTED] writes:
Jules Does 'ldd /usr/lib/libm.so' (to pick one example) work for
Jules you? It doesn't for me...
Yep, sure does.
libc6: 2.0.93-980414-1
ldso: 1.9.9-1
which are the latest that I'm aware of.
Jules I suspect these only
On 21 Jul 1998, Stephen Zander wrote:
Jules To satisfy my curiousity, would you execute the following
Jules on your machine:
Jules md5sum /usr/bin/ldd /lib/libc-2.0.93.so
3519891fb43b6a1d5ff81c9e69034359 /usr/bin/ldd
547e0385a5a3b8c604aa9a3b6d17323e /lib/libc-2.0.93.so
Jules == Jules Bean [EMAIL PROTECTED] writes:
Jules Well, actually, the intel versions of libc6 is 2.0.7pre.
Jules (while we're on a pre of 2.1) But anyway, it does rather
Jules sound like my problems are specific to my machine (which I
Jules doubt) or to the SS2 or 4c
I've been reading this list for a while now, so maybe I can answer a few
questions about Debian/sparc's status. I may be wrong about the status of
a few things, but if I am the main developers will probably hurry to correct
me, so here goes.
Debian sparc has some degree of problems with the
Michael Shuey writes:
I've been reading this list for a while now, so maybe I can answer a few
questions about Debian/sparc's status. I may be wrong about the status of
a few things, but if I am the main developers will probably hurry to correct
me, so here goes.
I would like to add the
On Tue, 21 Jul 1998, Joel Klecker wrote:
At 15:25 -0700 1998-07-21, Jules Bean wrote:
Well, not *all* that much. See my original message. Things that spring
to mind are - menu, lots of the graphics stuff (we have GIMP though,
yay!), libg++272 (not valuable in itself, but key to compiling
On Tue, 21 Jul 1998, Joel Klecker wrote:
At 17:06 -0700 1998-07-21, Jules Bean wrote:
To follow up my own message, it seems that we aren't using the glibc
version of ldd. I don't know why.
sparc has libc5, glibc ldd can't deal with libc5 binaries, ldso ldd handles
libc5 and libc6
On Wed, 22 Jul 1998, Jonas Oberg wrote:
latest version. In particular, someone should look into rebuilding mount.
That would fix several dependency problems.
Actually, I did this just a few hours ago :-) I've got a mount-2.7l,
debian revision 5 working just fine here. If someone could
Wow, just found it in my mirror - guess I should look there more often.
The FPE problem still exists though
Yes, but presumably this is your TurboSparc, and you're using the pathetic
attempt at TurboSparc support I did. The FPE problem is a) only interesting if
people (including you) with
I've been meaning to have a look at it, I just haven't had the time yet.
The repeat delay does seem rather short (I counted about 0.2 s), and
as far as I can tell it's kernel related (though, as I said, I haven't
really had the time to look at it yet).
I don't have any problem with any of
On Wed, 22 Jul 1998, Jules Bean wrote:
I tried to compile menu the other day, and it hit a lot of problems which
I tentatively diagnosed as being incompatibilities between the 'String.h'
provided by libstdc++2.8-dev and libg++272-dev. Maybe you'd have a quick
look and see if I'm right.
The
On Wed, 22 Jul 1998, Anders Hammarquist wrote:
That's an error I've seen more places. Try linking with g++ instead of
gcc and see if the errors go away. There are all sorts of tidbits that
Thanks, that did it. I'll put the menu_1.5-12_sparc.deb file on
ftp://home.broudy.net/pub/debian for now.
Stephen == Stephen Zander [EMAIL PROTECTED] writes:
Stephen Actually, my Sparc5/85 (non-Turbo) also had this problem.
Stephen I'm going to try loading the math-emu module I built as
Stephen part of the .35 kernel and see if it's fixed.
Following up on myself: loading math-emu.o
At 02:26 -0700 1998-07-22, Jonas Oberg wrote:
I am a debian developer. It's just that I'm not sure what to do about
these sparc packages, I mean, nothing is changed from the maintaners
package so it's an NMU, whilst at the same time it itsn't :-)
When I compiled the package for sparc, I got these
Hi all.
There seem to be quite a few problems with the sparc port, and I'm more
than happy to help - but this list seems to be almost dead. No one with
an 'air of authority' is around here...
I see the following problems with my SS2:
1) The boot disks don't work. Not an issue for me, but
I've had no problems with the boot disks on a Sparc 5. Just figured i'd
let everyone know. ;)
What I would like, and can't find, is a graphical Xclient. I tried just
tossing in Redhats CG6 client, but it didn't seem to work too well, and I
don't have the time right now to play with it. Any
You didn't Cc: your reply back to the list. In general, you should, since
my answers will be valuable to others. I am taking the liberty of Cc:ing
this all back to the list now.
On Tue, 21 Jul 1998, Michael Mattice wrote:
Jules Bean writes:
I see the following problems with my SS2:
On Tue, 21 Jul 1998, Chris Trainor wrote:
I've had no problems with the boot disks on a Sparc 5. Just figured i'd
let everyone know. ;)
What I would like, and can't find, is a graphical Xclient. I tried just
tossing in Redhats CG6 client, but it didn't seem to work too well, and I
OK, I found where to get the Xserver. I figured i'd just repost it here
again. ;)
ftp.netg.se:/pub/Linux/sparc/X
Has the deb packages for XSUN (CG3/6,etc) XSUN24 (zx, other 24bpp cards)
and Mono.
--Chris
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Jules == Jules Bean [EMAIL PROTECTED] writes:
Jules I'm glad I have a second. I now would like some response
Jules from the people who got the port as far as it is, so I know
Jules the current status of things...
Before you can get terribly far at all, you need a perl package (most
Jules == Jules Bean [EMAIL PROTECTED] writes:
Jules Huh?
Jules Perl works!
Wow, just found it in my mirror - guess I should look there more often.
The FPE problem still exists though
Jules I have 201 packages on my debian-sparc machine... including
Jules perl, X, ssh,
Thank god...
This list has been dead for a while. With the way the redhat sparc 5.0
release went i was afraid debian-sparc was going to go the way of the
dodo.
Let's get going...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Thank god...
This list has been dead for a while. With the way the redhat sparc 5.0
release went i was afraid debian-sparc was going to go the way of the
dodo.
Let's get going...
I hereby declare that I shall do all that is in my power to further
Debian-sparc.
Of course, since I'm stuck on
Everything is working mostly OK for me. I only have a few SunIPC's to play
with, and am waiting on a couple of large SCSI Hdd's for them before I can
go too mad.
The boot disks work fine on my IPC's too by the way.
Richard Parkinson Ph 64 7 8399090
50 matches
Mail list logo
