Porting to different architectures

Porting to different architectures

[chriscureau]

Hello, all!

I was glad to see that the ELKS project had a new maintainer...but when I saw that the distribution site was down, I thought I'd better check to see whether anyone was really still alive here.  Assuming there is someone out there reading my mail, I have two ideas to discuss...

A friend of mine and I are in the process of building a single board computer based on Western Design Center's 65c265, which is a 16-bit MCU which supports program sizes up to 64k, and data sizes up to the limit of memory (16M). Naturally, our first choice for an operating system for this hardware would be a unix-variant...and since ELKS is already coded for the 8086, we thought we could do a pretty straight port of it.  I'd really like to get the latest release, but unfortunately it looks as if Jody Bruchon's site is down.  

Actually, that brings me to my next idea...I have a server at home with a 6M/512k DSL connection.  I know, it's not a super fast connection, but it is available...and I would like to offer it to be used as a mirror for the ELKS project.  I will also offer whatever help I can for fixing the CVS repository, or perhaps considering with others a move to SVN.  

I hope that there is still life in this code yet...it would be rather nice to see Linux booting on our hardware. :-)

Thanks,
Chris Cureau

Re: Porting to different architectures

[Hans]

Hi Chris,

There are still a number of people on this list but most of us are in 
"screen saver" mode :-)

Porting ELKS to another (embedded) processor will definitely bring ELKS back 
to live (IMHO) but this is a huge and complicated task. Just changing the 
compiler from BCC to say Watcom is already a difficult task (I have to admit 
I am a hardware designer :-).

I tried Jody's http://compsolutions.ath.cx:88/elks/ site as well and indeed 
it looks down. I am pretty sure that one of us can email you the latest 
source files,

Hans
www.ht-lab.com


----- Original Message ----- 
From: <chriscureau@bellsouth.net>
To: <linux-8086@vger.kernel.org>
Sent: Monday, July 31, 2006 3:09 PM
Subject: Porting to different architectures


> Hello, all!
>
> I was glad to see that the ELKS project had a new maintainer...but when I 
> saw that the distribution site was down, I thought I'd better check to see 
> whether anyone was really still alive here.  Assuming there is someone out 
> there reading my mail, I have two ideas to discuss...
>
> A friend of mine and I are in the process of building a single board 
> computer based on Western Design Center's 65c265, which is a 16-bit MCU 
> which supports program sizes up to 64k, and data sizes up to the limit of 
> memory (16M). Naturally, our first choice for an operating system for this 
> hardware would be a unix-variant...and since ELKS is already coded for the 
> 8086, we thought we could do a pretty straight port of it.  I'd really 
> like to get the latest release, but unfortunately it looks as if Jody 
> Bruchon's site is down.
>
> Actually, that brings me to my next idea...I have a server at home with a 
> 6M/512k DSL connection.  I know, it's not a super fast connection, but it 
> is available...and I would like to offer it to be used as a mirror for the 
> ELKS project.  I will also offer whatever help I can for fixing the CVS 
> repository, or perhaps considering with others a move to SVN.
>
> I hope that there is still life in this code yet...it would be rather nice 
> to see Linux booting on our hardware. :-)
>
> Thanks,
> Chris Cureau
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Porting to different architectures

[Richard Wallman]

Hans wrote:
> There are still a number of people on this list but most of us are in
> "screen saver" mode :-)

I've been following this project for about 7 years now, and it seems
like it regularly goes into "screen saver" mode. :(

> Porting ELKS to another (embedded) processor will definitely bring ELKS
> back to live (IMHO) but this is a huge and complicated task. Just
> changing the compiler from BCC to say Watcom is already a difficult task

I've been working on getting it to work with GCC for 386+ processors,
and it's not pretty. GCC support would make porting a lot easier, given
the number of processor targets it supports.

The next trick would be to remove some of the PC-specific stuff - not
all systems have a BIOS, for example. I keep meaning to dig out the old
laptop I was given (286 based Toshiba thing) and get a serial console
working. I'm still keen to get it running on my Psion 3C. :)

> (I have to admit I am a hardware designer :-).

May come in useful... :)

> I am pretty sure that one of us can email you the latest source files

The SourceForge CVS server works, it's just the download instructions on
the site that are wrong.

If you replace "anonymous@cvs.sourceforge.net" with
"anonymous@elks.cvs.sourceforge.net" it all works well.

There doesn't seem to be any of the project admins (the ones with the
CVS SSH key) awake ATM - I was going to see if I could get a copy of the
key so that *someone* could commit changes! Failing that, I would
(reluctantly) have to fork the project just to keep things moving.

So, project admins - anyone awake?

-- 
Richard Wallman

Re: Porting to different architectures

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Richard Wallman wrote:
[...]
> I've been working on getting it to work with GCC for 386+ processors,
> and it's not pretty. GCC support would make porting a lot easier, given
> the number of processor targets it supports.

Is anyone interested in hearing that I've nearly managed to get the ACK
(Minix' native compiler) into a usable state? It supports ANSI C, K&R C,
Pascal, Modula-2, Occam and Basic for a bunch of different
architectures, which include i80, i86 and i386. The code isn't as good
as what gcc produces, but it is a tiny fraction of the size, and it's
also BSD licensed.

I'm still working on the syscall libraries required for the ACK's own
built-in libc, but if you didn't want to use that, it's more or less
there now.

(It should also be reasonably easy to retarget --- compared to gcc, at
least. Does the 65C265 have a compiler?)

-- 
+- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_
|  dg@cowlark.com    | until you have read it in the original Klingon."
| (dg@tao-group.com) | --- Sea Wasp on r.a.sf.w
+- www.cowlark.com --+


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: Porting to different architectures

[Richard Wallman]

David Given wrote:
> Is anyone interested in hearing that I've nearly managed to get the ACK
> (Minix' native compiler) into a usable state?

Running under ELKS, or to compile ELKS?

If it's running under ELKS, that would be good - I've been using
OnboardC on my Palm, but the lack of a keyboard makes
coding...interesting. My Psion 3C has a nice keyboard, though, so coding
on the train would be a possibility. :)

-- 
Richard Wallman

Re: Porting to different architectures

[David Given]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

Richard Wallman wrote:
[...]
> Running under ELKS, or to compile ELKS?

Neither --- cross-compiling from some big operating system to generic
i86 code. It *may* be possible to cross-compile the ACK so that it runs
on ELKS; after all, Minix i86 did that, and it has the same code size
restrictions ELKS does. However, this isn't a priority right now.

There ought to be enough there now to build standalone images, though.

-- 
+- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_
|  dg@cowlark.com    | until you have read it in the original Klingon."
| (dg@tao-group.com) | --- Sea Wasp on r.a.sf.w
+- www.cowlark.com --+


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: Porting to different architectures

[Jody Bruchon]

I'm here.

My main machine (the host) had an Athlon XP barbecue.

I'm using a temporary Linux box but haven't gotten around to putting 
thttpd on it yet.

I'll see what I can do, but I'll definitely need someone to mail me the 
ELKS source tarball again so I can put it back up.  I've got real UNIX 
now, so you won't see CRLF problems anymore :)

Also, I have full access to the entire ELKS project.  Mail me if you 
need stuff done and I'll try to take care of it.

Thanks!

Jody

Richard Wallman wrote:
> Hans wrote:
>> There are still a number of people on this list but most of us are in
>> "screen saver" mode :-)
> 
> I've been following this project for about 7 years now, and it seems
> like it regularly goes into "screen saver" mode. :(
> 
>> Porting ELKS to another (embedded) processor will definitely bring ELKS
>> back to live (IMHO) but this is a huge and complicated task. Just
>> changing the compiler from BCC to say Watcom is already a difficult task
> 
> I've been working on getting it to work with GCC for 386+ processors,
> and it's not pretty. GCC support would make porting a lot easier, given
> the number of processor targets it supports.
> 
> The next trick would be to remove some of the PC-specific stuff - not
> all systems have a BIOS, for example. I keep meaning to dig out the old
> laptop I was given (286 based Toshiba thing) and get a serial console
> working. I'm still keen to get it running on my Psion 3C. :)
> 
>> (I have to admit I am a hardware designer :-).
> 
> May come in useful... :)
> 
>> I am pretty sure that one of us can email you the latest source files
> 
> The SourceForge CVS server works, it's just the download instructions on
> the site that are wrong.
> 
> If you replace "anonymous@cvs.sourceforge.net" with
> "anonymous@elks.cvs.sourceforge.net" it all works well.
> 
> There doesn't seem to be any of the project admins (the ones with the
> CVS SSH key) awake ATM - I was going to see if I could get a copy of the
> key so that *someone* could commit changes! Failing that, I would
> (reluctantly) have to fork the project just to keep things moving.
> 
> So, project admins - anyone awake?
> 

Re: Porting to different architectures

[Richard Wallman]

Jody Bruchon wrote:

> My main machine (the host) had an Athlon XP barbecue.

Heh - I had one over the weekend. Sorting out my Dad's computer, IDE cable got
in the way of the CPU fan and I didn't notice until it started a reset loop.
It took a couple of minutes before it cooled down enough for the motherboard
to be willing/able to report the CPU temperature - apparently it can't report
temperatures over 99 degrees C. Amazing thing it, it still works!

Cup of tea, anyone? :P

> I'll see what I can do, but I'll definitely need someone to mail me the
> ELKS source tarball again so I can put it back up.

Why put tarballs on a separate site when the SourceForge tools work? If CVS is
good to go, that's a lot easier to manage that manually patching and releasing
tarballs, especially when (and I'm being optimistic and not saying 'if') there
are multiple developers working on different things.

You could always create tarballs from a CVS export, and if SF host it then you
don't have to worry about your computer/bandwidth/etc.

> Also, I have full access to the entire ELKS project.  Mail me if you
> need stuff done and I'll try to take care of it.

Do you have the SSH key needed for CVS commits?
Do you have the rights needed to add/remove project admins/developers?

I posted a PATCH a while back that adds the ability to select the root device
at compile time - I'd like that tested and committed, if possible.

-- 
Richard Wallman

            Where are we going, and why am I in this handbasket?

Re: Porting to different architectures

[Segin]

Richard Wallman wrote:
> Jody Bruchon wrote:
> 
> 
>>My main machine (the host) had an Athlon XP barbecue.
> 
> 
> Heh - I had one over the weekend. Sorting out my Dad's computer, IDE cable got
> in the way of the CPU fan and I didn't notice until it started a reset loop.
> It took a couple of minutes before it cooled down enough for the motherboard
> to be willing/able to report the CPU temperature - apparently it can't report
> temperatures over 99 degrees C. Amazing thing it, it still works!
> 
> Cup of tea, anyone? :P
I had a system do a similar thing cause the fan get it's power via the 
disk drive power cables, and if the wires are put in a certain position, 
the fan quits working. At any rate, when I rebooted, i got a "Power 
Managemenr failure" from the BIOS, checking it out revealed that the CPU 
was roasting at a good 253 degrees, while running. Luckly it didn't break.

-- 
The real problem with C++ for kernel modules is: the language just sucks.
	-- Linus Torvalds

Re: Porting to different architectures

[Javier Sedano]

Hi,

Richard Wallman wrote:
> 
> There doesn't seem to be any of the project admins (the ones with the
> CVS SSH key) awake ATM - I was going to see if I could get a copy of the
> key so that *someone* could commit changes! Failing that, I would
> (reluctantly) have to fork the project just to keep things moving.
> 

	I think there is a (slow, painful, bureaucratic) mechanism to retake 
abandoned projects. If you really want to do it, mail the sourceforge 
team to look for a solution.


> So, project admins - anyone awake?
> 

	You can also try to mail to their sourceforge accounts 
(user@sourceforge.net, or something similar). I think it is forwarded to 
a real account (at least, it is forwarded in my case).

-- 
Javier Sedano Jarillo: javier.sedano@agora-2000.com
Agora Systems S.A.
C/Velazquez, 46, 6º derecha;    E-28001 Madrid (Spain)
Tel.: +34 676 48 29 55;         Fax.: +34 91 577 76 72
--------
Más vale ser cobarde un minuto que muerto todo el resto de la vida.
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Porting to different architectures

[Alan Cox]

Ar Llu, 2006-07-31 am 21:47 +0200, ysgrifennodd Javier Sedano:
> Hi,
> 
> Richard Wallman wrote:
> > 
> > There doesn't seem to be any of the project admins (the ones with the
> > CVS SSH key) awake ATM - I was going to see if I could get a copy of the
> > key so that *someone* could commit changes! Failing that, I would
> > (reluctantly) have to fork the project just to keep things moving.
> > 
> 
> 	I think there is a (slow, painful, bureaucratic) mechanism to retake 
> abandoned projects. If you really want to do it, mail the sourceforge 
> team to look for a solution.

If you plan to use it as the basis for a new OS for something else I
would fork it. The existing project is as good as dead and it's probably
easier to just turn it into what you need than worry about breaking the
existing code.

Alan

Re: Porting to different architectures

[Tom McCabe]

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Ar Llu, 2006-07-31 am 21:47 +0200, ysgrifennodd
> Javier Sedano:
> > Hi,
> > 
> > Richard Wallman wrote:
> > > 
> > > There doesn't seem to be any of the project
> admins (the ones with the
> > > CVS SSH key) awake ATM - I was going to see if I
> could get a copy of the
> > > key so that *someone* could commit changes!
> Failing that, I would
> > > (reluctantly) have to fork the project just to
> keep things moving.
> > > 
> > 
> > 	I think there is a (slow, painful, bureaucratic)
> mechanism to retake 
> > abandoned projects. If you really want to do it,
> mail the sourceforge 
> > team to look for a solution.
> 
> If you plan to use it as the basis for a new OS for
> something else I
> would fork it. The existing project is as good as
> dead and it's probably
> easier to just turn it into what you need than worry
> about breaking the
> existing code.

Agreed. We can keep the current version for historical
purposes, and if someone wants to build a better OS
for ancient machines, there are more popular and
better designs than the 8088.

> Alan
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Porting to different architectures

[Jody Bruchon]

On top of that, the 8088 isn't really even used in embedded stuff 
anymore AFAIK.  From what I understand, the embedded Intel CPU of choice 
is an i386EX and that likely can run Linux unmodified.

The biggest problem I see with ELKS is that it has a lot of features, 
and 90% of said features are either broken, unimplemented, or 
half-functional.  Furthermore, we're so lacking in knowledgeable kernel 
developers with TIME available to work on the project that it's not 
going to go anywhere.

Compounding the problems is the fact that bcc has proven time and time 
again to be a very volatile compiler package, to the point that even one 
version revision can mean the difference between successful compilation 
or errors galore.

On a side note, I'm developing an OS for the 6502/65C02/65816 line of 
CPUs from Western Design Center, if anyone's interested in that kind of 
stuff.

~Jody

Tom McCabe wrote:
> 
> --- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
>> Ar Llu, 2006-07-31 am 21:47 +0200, ysgrifennodd
>> Javier Sedano:
>>> Hi,
>>>
>>> Richard Wallman wrote:
>>>> There doesn't seem to be any of the project
>> admins (the ones with the
>>>> CVS SSH key) awake ATM - I was going to see if I
>> could get a copy of the
>>>> key so that *someone* could commit changes!
>> Failing that, I would
>>>> (reluctantly) have to fork the project just to
>> keep things moving.
>>> 	I think there is a (slow, painful, bureaucratic)
>> mechanism to retake 
>>> abandoned projects. If you really want to do it,
>> mail the sourceforge 
>>> team to look for a solution.
>> If you plan to use it as the basis for a new OS for
>> something else I
>> would fork it. The existing project is as good as
>> dead and it's probably
>> easier to just turn it into what you need than worry
>> about breaking the
>> existing code.
> 
> Agreed. We can keep the current version for historical
> purposes, and if someone wants to build a better OS
> for ancient machines, there are more popular and
> better designs than the 8088.
> 
>> Alan
>>
>> -
>> To unsubscribe from this list: send the line
>> "unsubscribe linux-8086" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at 
>> http://vger.kernel.org/majordomo-info.html
>>
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Porting to different architectures

[Alan Cox]

Ar Maw, 2006-08-01 am 01:27 -0400, ysgrifennodd Jody Bruchon:
> On top of that, the 8088 isn't really even used in embedded stuff 
> anymore AFAIK.  From what I understand, the embedded Intel CPU of choice 
> is an i386EX and that likely can run Linux unmodified.

Some of the embedded 386 chips can some can't. Not all of them have a
paging MMU some have just segmentation. Nowdays the CPU of choice seems
to be either the VIA fanless processors or the AMD (ex Nat Semi) Geode
system on a chip, both of which are Pentium class or higher

Re: Porting to different architectures

[Vikas N Kumar]

Agreed... What about MIPS chips ? I hear they are pretty popular.
And what about custom FPGA chips ? I am not an Elec... engineer, but I
am interested as to what kind of operating systems do custom FPGA
chips run ?

regards,
Vikas
On 8/1/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Maw, 2006-08-01 am 01:27 -0400, ysgrifennodd Jody Bruchon:
> > On top of that, the 8088 isn't really even used in embedded stuff
> > anymore AFAIK.  From what I understand, the embedded Intel CPU of choice
> > is an i386EX and that likely can run Linux unmodified.
>
> Some of the embedded 386 chips can some can't. Not all of them have a
> paging MMU some have just segmentation. Nowdays the CPU of choice seems
> to be either the VIA fanless processors or the AMD (ex Nat Semi) Geode
> system on a chip, both of which are Pentium class or higher
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Porting to different architectures

[Hans]

----- Original Message ----- 
From: "Vikas N Kumar" <vikasnkumar@users.sourceforge.net>
To: <linux-8086@vger.kernel.org>
Sent: Tuesday, August 01, 2006 3:41 PM
Subject: Re: Porting to different architectures


> Agreed... What about MIPS chips ? I hear they are pretty popular.

I believe that ARM has the number 1,2 and 3 spot in the embedded processor 
space :-)

> And what about custom FPGA chips ? I am not an Elec... engineer, but I
> am interested as to what kind of operating systems do custom FPGA
> chips run ?

uCLinux has been ported to both Altera's NIOS and Xilinx Microblaze 
processors but I am not sure how many users are using it. I suspect that for 
a lot of embedded systems Linux might be an overkill.

Regards,
Hans
www.ht-lab.com


>
> regards,
> Vikas
> On 8/1/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Ar Maw, 2006-08-01 am 01:27 -0400, ysgrifennodd Jody Bruchon:
>> > On top of that, the 8088 isn't really even used in embedded stuff
>> > anymore AFAIK.  From what I understand, the embedded Intel CPU of 
>> > choice
>> > is an i386EX and that likely can run Linux unmodified.
>>
>> Some of the embedded 386 chips can some can't. Not all of them have a
>> paging MMU some have just segmentation. Nowdays the CPU of choice seems
>> to be either the VIA fanless processors or the AMD (ex Nat Semi) Geode
>> system on a chip, both of which are Pentium class or higher
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Porting to different architectures

[Petr Koval]

On Mon, 31 Jul 2006 10:09:41 -0400
<chriscureau@bellsouth.net> wrote:

[..]

> Actually, that brings me to my next idea...I have a server at home with a 6M/512k DSL connection.  I know, it's not a super fast connection, but it is available...and I would like to offer it to be used as a mirror for the ELKS project.  I will also offer whatever help I can for fixing the CVS repository, or perhaps considering with others a move to SVN.  

do you can mirror the http://compsolutions.ath.cx:88/elks/ (http://elks.sourceforge.net/download.html) soon as possible?
i often have problem to access, for example now

# traceroute compsolutions.ath.cx
traceroute to cpe-066-057-079-209.nc.res.rr.com (66.57.79.209), 30 hops max, 40 byte packets
 1  pavilion (10.10.10.1)  1.042 ms  0.595 ms  0.491 ms
 2  chello212017080001.9.15.vie.surfer.at (212.17.80.1)  9.241 ms  8.599 ms  7.290 ms
 3  at-vie-pe-sr15a-ge-3-3.upc.at (212.17.116.58)  12.153 ms  8.952 ms  8.183 ms

[..]

23  pos7-0.rlghnca-rtr2.nc.rr.com (24.25.0.10)  131.078 ms  130.711 ms  131.201 ms
24  srp1-0.rlghncy-ubr1.nc.rr.com (24.25.2.165)  132.106 ms  131.574 ms  130.813 ms
25  cpe-066-057-079-209.nc.res.rr.com (66.57.79.209)  138.969 ms  139.848 ms  141.627 ms

# nmap 66.57.79.209 -p88

PORT   STATE    SERVICE
88/tcp filtered kerberos-sec

http://[url]:88/elks get not any data

and my local backup is

File: elks-20060503.tar.bz2  	1337 KB  	2006-05-04  	05:53:03
File: elks-20060503.tar.bz2.md5sum 	1 KB 	2006-05-23 	04:13:18
File: elks-20060503.tar.bz2.sha1sum 	1 KB 	2006-05-23 	04:14:27
File: elks-20060506.tar.bz2 	1337 KB 	2006-05-06 	21:06:25
File: elks-20060506.tar.bz2.md5sum 	1 KB 	2006-05-23 	04:13:18
File: elks-20060506.tar.bz2.sha1sum 	1 KB 	2006-05-23 	04:14:27
File: elks-20060508.tar.bz2 	1334 KB 	2006-05-13 	06:32:15
File: elks-20060508.tar.bz2.md5sum 	1 KB 	2006-05-23 	04:13:18
File: elks-20060508.tar.bz2.sha1sum 	1 KB 	2006-05-23 	04:14:27
File: elks-20060515.tar.bz2 	1337 KB 	2006-05-15 	07:12:49
File: elks-20060515.tar.bz2.md5sum 	1 KB 	2006-05-23 	04:13:19
File: elks-20060515.tar.bz2.sha1sum 	1 KB 	2006-05-23 	04:14:27
File: elks-20060516.tar.bz2 	1336 KB 	2006-05-17 	04:53:41
File: elks-20060516.tar.bz2.md5sum 	1 KB 	2006-05-23 	04:13:19
File: elks-20060516.tar.bz2.sha1sum 	1 KB 	2006-05-23 	04:14:28
File: elks-20060521.tar.bz2 	1335 KB 	2006-05-22 	04:56:30
File: elks-20060521.tar.bz2.md5sum 	1 KB 	2006-05-23 	04:13:19
File: elks-20060521.tar.bz2.sha1sum 	1 KB 	2006-05-23 	04:14:28
File: images-test-20060517.zip 	1190 KB 	2006-05-18 	06:35:10
File: images-test-20060517.zip.md5sum 	1 KB 	2006-05-23 	04:15:32
File: images-test-20060517.zip.sha1sum 	1 KB 	2006-05-23 	04:15:40

regards
Petr "DjHawk" Koval

CVS access

[Mattia Jona-Lasinio]

The sourceforge site has change their names for CVS access. Now there is a 
CVS access using

cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks login
cvs -z3 -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks co modulename


Are the files retrieved using this site up to date? Or are they completely 
outdated?

Thanks!

Regards,

 	Mattia

Re: CVS access

[Petr Koval]

On Mon, 31 Jul 2006 17:29:29 +0200 (CEST)
Mattia Jona-Lasinio <mjona@lkb.ens.fr> wrote:

> The sourceforge site has change their names for CVS access. Now there is a 
> CVS access using
> 
> cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks login
> cvs -z3 -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks co modulename
> 
> 
> Are the files retrieved using this site up to date? Or are they completely 
> outdated?

pavilion CVSROOT # cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks login
Logging in to :pserver:anonymous@elks.cvs.sourceforge.net:2401/cvsroot/elks
CVS password:
pavilion CVSROOT # cvs -z3 -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks co elks
cvs checkout: Updating elks
U elks/BUGS

[..]

cvs checkout: Updating elks/video/vt52
U elks/video/vt52/Makefile
U elks/video/vt52/vt52.html


pavilion elks # less /CVSROOT/elks/RELNOTES

ELKS RELEASE NOTES
~~~~~~~~~~~~~~~~~~

VERSION 0.0.89-PRE1 NOTES
-------------------------

Answer: outdated

but good to know cvs works again

Reagards
Petr "DjHawk" Koval

Re: CVS access

[Petr Koval]

On Mon, 31 Jul 2006 17:29:29 +0200 (CEST)
Mattia Jona-Lasinio <mjona@lkb.ens.fr> wrote:

> The sourceforge site has change their names for CVS access. Now there is a 
> CVS access using
> 
> cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks login
> cvs -z3 -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks co modulename

modulename elks is accessable
modulenames elksnet,elkscmd, etc are not

pavilion CVSROOT # cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elksnet login
Logging in to :pserver:anonymous@elks.cvs.sourceforge.net:2401/cvsroot/elksnet
CVS password:
cvs login: authorization failed: server elks.cvs.sourceforge.net rejected access to /cvsroot/elksnet for user anonymous
pavilion CVSROOT # cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elkscmd login
Logging in to :pserver:anonymous@elks.cvs.sourceforge.net:2401/cvsroot/elkscmd
CVS password:
cvs login: authorization failed: server elks.cvs.sourceforge.net rejected access to /cvsroot/elkscmd for user anonymous

does anybody have thouse two modules? (no problem when old data)

Regards
Petr "DjHawk" Koval

Re: CVS access

[Mattia Jona-Lasinio]

On Mon, 31 Jul 2006, Petr Koval wrote:

> On Mon, 31 Jul 2006 17:29:29 +0200 (CEST)
> Mattia Jona-Lasinio <mjona@lkb.ens.fr> wrote:
>
>> The sourceforge site has change their names for CVS access. Now there is a
>> CVS access using
>>
>> cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks login
>> cvs -z3 -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks co modulename
>
> modulename elks is accessable
> modulenames elksnet,elkscmd, etc are not
>
> pavilion CVSROOT # cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elksnet login
> Logging in to :pserver:anonymous@elks.cvs.sourceforge.net:2401/cvsroot/elksnet
> CVS password:
> cvs login: authorization failed: server elks.cvs.sourceforge.net rejected access to /cvsroot/elksnet for user anonymous
> pavilion CVSROOT # cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elkscmd login
> Logging in to :pserver:anonymous@elks.cvs.sourceforge.net:2401/cvsroot/elkscmd
> CVS password:
> cvs login: authorization failed: server elks.cvs.sourceforge.net rejected access to /cvsroot/elkscmd for user anonymous

The cvsroot should not be changed. the following is correct.

cvs -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks login
cvs -z3 -d:pserver:anonymous@elks.cvs.sourceforge.net:/cvsroot/elks co modulename

where modulename is one of

elks		the true elks project
elks-0.2	seems to be empty
elks-0.3	seems to be empty
elkscmd		shells, editors and other stuff
elksnet		sort of tcp/ip stack
elkspages	seems to be the website
elksutils	seems to be empty
elksweb		again the website
elksweb2	still the website


Bye,

 	M