Date: Sat, 2 Jul 2005 00:05:18 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 573 ************************************************** Friday 01 July 2005 Number 573 ************************************************** Subjects for today 1 Re: Building latest Perl : Dale A Cook 2 Re: Building latest Perl : John Poltorak 3 Re: The OS/2 and eCS Ecosystem : billn 4 Re: CPAN : Dave Yeo" 5 Re: The OS/2 and eCS Ecosystem : Dave Yeo" 6 Re: The OS/2 and eCS Ecosystem : mikus at bga.com (Mikus Grinbergs) 7 Re: CPAN : John Poltorak 1 Re: The OS/2 and eCS Ecosystem : John Poltorak 8 Re: CPAN : Dave Saville" 2 Re: The OS/2 and eCS Ecosystem : Stefan.Neis at t-online.de 9 Re: CPAN : John Poltorak 3 Re: CPAN : Lyn St George" 10 Re: The OS/2 and eCS Ecosystem : John Poltorak 4 Re: The OS/2 and eCS Ecosystem : John Poltorak 11 Re: The OS/2 and eCS Ecosystem : Knut St. Osmundsen" 5 make 3.81 Beta 3 : Andreas Buening 12 Re: The OS/2 and eCS Ecosystem : John Poltorak 6 Re: The OS/2 and eCS Ecosystem : Andreas Buening 13 Re: The OS/2 and eCS Ecosystem : billn 7 Re: The OS/2 and eCS Ecosystem : John Poltorak 14 Re: The OS/2 and eCS Ecosystem : John Poltorak 8 Re: CPAN : Dave Yeo" 15 Re: The OS/2 and eCS Ecosystem : mentore\.siesto\ at libero\.it" 9 Re: CPAN : John Poltorak 10 Re: The OS/2 and eCS Ecosystem : Stefan.Neis at t-online.de 16 Re: The OS/2 and eCS Ecosystem : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Thu, 30 Jun 2005 10:10:37 -0400 From: Dale A Cook Subject: Re: Building latest Perl Please excuse but, WTF IS PEARL ????????? TIA!!! John Poltorak wrote: > On Thu, Jun 30, 2005 at 12:57:54PM +0200, Stefan.Neis at t-online.de wrote: > >>John Poltorak schrieb: >> >> >>>I wouldn't expect so... Perl is heavily tied >>>up with EMX AFAIK. >> >>Not really. The only issue is that it adds a >>couple of things that are missing in EMX. If >>you replace EMX by something which already >>has said missing stuff (Posix/2 or Innotek's >>libc), you get conflicts, but it should be >>possible to resolve them by just removing a >>bit of OS/2 specific code form Perl sources... > > > Doesn't sound like a trivial task to me... I also don't see IlyaZ > embracing Innotek's libc anytime soon which means we may have a split in > support for the OS/2 port of Perl, unless someone comes forward as the new > maintainer. > > > >> Regards, >> Stefan > > > **= Email 2 ==========================** Date: Thu, 30 Jun 2005 15:43:20 +0100 From: John Poltorak Subject: Re: Building latest Perl On Thu, Jun 30, 2005 at 10:10:37AM -0400, Dale A Cook wrote: > Please excuse but, WTF IS PEARL ????????? TIA!!! You can find out everything you want to know about PERL here:- http://www.perl.org/ > > John Poltorak wrote: > > On Thu, Jun 30, 2005 at 12:57:54PM +0200, Stefan.Neis at t-online.de wrote: > > > >>John Poltorak schrieb: > >> > >> > >>>I wouldn't expect so... Perl is heavily tied > >>>up with EMX AFAIK. > >> > >>Not really. The only issue is that it adds a > >>couple of things that are missing in EMX. If > >>you replace EMX by something which already > >>has said missing stuff (Posix/2 or Innotek's > >>libc), you get conflicts, but it should be > >>possible to resolve them by just removing a > >>bit of OS/2 specific code form Perl sources... > > > > > > Doesn't sound like a trivial task to me... I also don't see IlyaZ > > embracing Innotek's libc anytime soon which means we may have a split in > > support for the OS/2 port of Perl, unless someone comes forward as the new > > maintainer. > > > > > > > >> Regards, > >> Stefan > > > > > > > -- John **= Email 3 ==========================** Date: Thu, 30 Jun 2005 07:56:13 -0700 From: billn Subject: Re: The OS/2 and eCS Ecosystem I'm planning on working with the GCC 3.3.5b5 when I get some time. Right now my FreeBSD system is down, my W2KServer is misbehaving and won't recognize the new 250 GB drive, and my security system needs to be built and installed. So it will be a while. I'll let you know when I work on it. BillN John Poltorak wrote: > > On Sun, Jun 26, 2005 at 07:55:09AM -0700, billn wrote: > > > The kicker in all of this is getting more developers on board. In > > particular, if we had an easy to install development environment that > > would install on OS/2 *or* Linux, we could invite Linux developers to > > build OS/2 versions of their current applications, and have the ability > > to build custom applications w/o having to spend large amounts of time > > in the install and tuning of a development tool. > > Have you ever tried installing UX2BS? > > > BillN > > -- > John **= Email 4 ==========================** Date: Thu, 30 Jun 2005 08:04:17 -0800 From: "Dave Yeo" Subject: Re: CPAN On Thu, 30 Jun 2005 12:32:56 +0100, John Poltorak wrote: >Can you give me an example of what CPAN does on Unix which doesn't work on >OS/2? > >If the OS/2 port is broken we should get it fixed. Try this in a cmd prompt with UX2BS installed (it fails here eventually with my own enviroment) perl -MCPAN -e shell o conf prerequisites_policy ask install Mail::SpamAssassin quit Dave **= Email 5 ==========================** Date: Thu, 30 Jun 2005 08:12:23 -0800 From: "Dave Yeo" Subject: Re: The OS/2 and eCS Ecosystem On Thu, 30 Jun 2005 10:17:39 +0100, John Poltorak wrote: > >Moztools is a hotch potch of utils assembled together purely for building >Mozilla. Some are dependent on other utils being in this collection, >others are not and can be replaced by other utils located wherever you >want to put them. It is a bit of a minefield trying to deconstruct this >toolset, but I would like to incorporate the whole thing into UX2BS at >some point. One of the problems is that certain apps depend on the the use >of ASH as the shell and are hardwired for its use, but I would like to >replace the whole thing at some point. I think the only place that ASH is hardwired is a %MAKESHELL% and %CONFIG_SHELL% in setmozenv.cmd. Anyways what is wrong with using ASH as the makeshell? Much faster then bash or ksh. Just have to work around a bug by puuting something like x:\foo at the beginning of %PATH% IIRC having a similar directory structure as the porters is hardwired in configure, shouldn't be hard to change. Dave **= Email 6 ==========================** Date: Thu, 30 Jun 2005 09:09:15 -0500 From: mikus at bga.com (Mikus Grinbergs) Subject: Re: The OS/2 and eCS Ecosystem On Thu, 30 Jun 2005 10:17:39 +0100 John Poltorak wrote: > On Wed, Jun 29, 2005 at 01:43:34PM -0700, Steven Levine wrote: > > In <42C2C6D3.5040609 at comcast.net>, on 06/29/05 > > at 10:05 AM, Andy Willis said: > > > > >The advantage would come if a certain app you were building were looking > > >for its tools there. I have mine in the moztools directory and have yet > > >for it to be an issue so I haven't yet bothered to move them to usr. > > > > The only real advantage of moztools is to hold tools that must be specific > > versions for building Mozilla. I plan to know soon if any of these still > > exist. > > Moztools is a hotch potch of utils assembled together purely for building > Mozilla. Some are dependent on other utils being in this collection, > others are not and can be replaced by other utils located wherever you > want to put them. It is a bit of a minefield trying to deconstruct this > toolset, but I would like to incorporate the whole thing into UX2BS at > some point. One of the problems is that certain apps depend on the the use > of ASH as the shell and are hardwired for its use, but I would like to > replace the whole thing at some point. I happen to have my own preferences as to where to put tools. The philosophy I have settled upon is to set up a "customized" session, that has access to all the specialized tools needed for a particular development function, and then run that function within that session. For instance I set up a general session for gcc 3.3.5 compiles; and set up a "special" session specifically for Mozilla compiles. I use batch scripts (.cmd files) to equip these sessions - they supply access to all the resources needed by the particular function they support. For example, they supply all needed environmental variables, and set up the PATH and BEGINLIBPATH to access all needed tools. Those tools which can be used by many functions/applications go into "general" directories (which are accessed through CONFIG.SYS). Those tools which are used by few functions go into "segregated" directories, which are then made accessible by the script which equips the session for the using function. I do __not__ have any directory in my system called 'moztools'. The tools needed for a Mozilla compile are scattered in MANY places in my system; the script (based on setmozenv) which equips the session for the Mozila compile "pulls them all together". mikus **= Email 7 ==========================** Date: Thu, 30 Jun 2005 17:16:14 +0100 From: John Poltorak Subject: Re: CPAN On Thu, Jun 30, 2005 at 08:04:17AM -0800, Dave Yeo wrote: > On Thu, 30 Jun 2005 12:32:56 +0100, John Poltorak wrote: > > >Can you give me an example of what CPAN does on Unix which doesn't work on > >OS/2? > > > >If the OS/2 port is broken we should get it fixed. > > Try this in a cmd prompt with UX2BS installed (it fails here eventually with my own enviroment) > perl -MCPAN -e shell This the first time I've used Perl on this system so the CPAN configuration will need initialising and as with all manual setups it is error prone. Should I go for all the defaults? Is there a log of setting it up so that I can refer to it subsequently? Wonder if there is a way to set it up automatically... Something has got screwed up anyway so I need to start again, not sure what happens in the case of an incomplete configuration... > o conf prerequisites_policy ask > install Mail::SpamAssassin > quit > Dave > -- John **= Email 1 ==========================** Date: Thu, 30 Jun 2005 17:42:26 +0100 From: John Poltorak Subject: Re: The OS/2 and eCS Ecosystem On Thu, Jun 30, 2005 at 08:12:23AM -0800, Dave Yeo wrote: > On Thu, 30 Jun 2005 10:17:39 +0100, John Poltorak wrote: > > > > >Moztools is a hotch potch of utils assembled together purely for building > >Mozilla. Some are dependent on other utils being in this collection, > >others are not and can be replaced by other utils located wherever you > >want to put them. It is a bit of a minefield trying to deconstruct this > >toolset, but I would like to incorporate the whole thing into UX2BS at > >some point. One of the problems is that certain apps depend on the the use > >of ASH as the shell and are hardwired for its use, but I would like to > >replace the whole thing at some point. > > I think the only place that ASH is hardwired is a %MAKESHELL% and > %CONFIG_SHELL% in setmozenv.cmd. It's in GLIB and LIBIDL. > Anyways what is wrong with using ASH > as the makeshell? Much faster then bash or ksh. Just have to work > around a bug by puuting something like x:\foo at the beginning of > %PATH% I settled on PDKSH a long time ago - had problems with everything else and no other shell can be used for building Perl AFAIK so I stuck with just this one. UX2BS works with PDKSH. I could get ASH to work - don't remember why, but in the interests of efficiency I would like to give it a try just to see the difference in performance. > IIRC having a similar directory structure as the porters is hardwired > in configure, shouldn't be hard to change. > Dave > -- John **= Email 8 ==========================** Date: Thu, 30 Jun 2005 17:49:52 +0100 (BST) From: "Dave Saville" Subject: Re: CPAN On Thu, 30 Jun 2005 12:32:56 +0100, John Poltorak wrote: >Can you give me an example of what CPAN does on Unix which doesn't work on >OS/2? > >If the OS/2 port is broken we should get it fixed. I can't recall what I was trying to do but it involved a load of encryption/html/network type stuff. It fetches OK it's when it tries to install that it breaks. Of course that module may well have failed anyway doing it manually. -- Regards Dave Saville **= Email 2 ==========================** Date: Thu, 30 Jun 2005 19:35:40 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: The OS/2 and eCS Ecosystem Dave Yeo schrieb: > I think the only place that ASH is hardwired > is a %MAKESHELL% and %CONFIG_SHELL% in > setmozenv.cmd. Anyways what is wrong > with using ASH as the makeshell? It's broken in some of the more esoteric areas (i.e. not quite conforming to current POSIX standard). wxWidgets currently has a work-around in it's build system to make everything work with ash under OS/2 (that way configure runs about 20% faster), but if you now run the scripts under (pd)ksh, some of the generated scripting code is broken - and repairing it for (pd)ksh or any other standard conforming shell is going to break it for ash. Regards, Stefan **= Email 9 ==========================** Date: Thu, 30 Jun 2005 20:26:46 +0100 From: John Poltorak Subject: Re: CPAN On Thu, Jun 30, 2005 at 07:40:34PM +0100, Lyn St George wrote: > On Thu, 30 Jun 2005 12:06:53 +0100 (BST), Dave Saville wrote: > > >On Thu, 30 Jun 2005 11:07:39 +0100, John Poltorak wrote: > > > >> > >>Is anyone familiar with using CPAN? In particular I mean the Perl CPAN > >>function which can be used for automatically retrieving and installing > >>Perl modules? > >> > >>I need some guidance on how it is supposed to work. > > > >In theory you give it the module you want installed and go and make the tea. In > >practise on OS/2 it usually goes wrong :-( I find it easier to go FTP what I > >need. Where the CPAN thing pays off is where you need tons of packages that all > >cross relate to get some feature or other installed. But as I said that is when > >it usually fails. I would think on *nix it is pretty solid. > > I had this working as part of an experimental UX2 build system once. > As I recall, it was just a matter of adding lines to the build_perl.cmd to > install the CPAN module, then copy in a pre-configured config.pm (no > worse than having to patch other things), and then running lines like > perl -MCPAN -e install CGI > so that you ended up with a perl complete with some useful modules. > > ISTR that this worked as well on OS/2 as it does on other platforms. I've tried it again after adding WGET to the path and configuring things for working through a proxy server and it works to some extent, but there is a problem with the format of the files retrieved to ~/.cpan/sources. MIRRORED.BY appears as a standard text file but the gzipped files such as 01mailrc.txt.gz appear to be corrupted. I have a sneaking suspicion that this corruption has been created by this build of Perl. Your Perl is probably an older version. > >-- > >Regards > > > >Dave Saville > > > > > > > > > - > Lyn > -- John **= Email 3 ==========================** Date: Thu, 30 Jun 2005 19:40:34 +0100 (BST) From: "Lyn St George" Subject: Re: CPAN On Thu, 30 Jun 2005 12:06:53 +0100 (BST), Dave Saville wrote: >On Thu, 30 Jun 2005 11:07:39 +0100, John Poltorak wrote: > >> >>Is anyone familiar with using CPAN? In particular I mean the Perl CPAN >>function which can be used for automatically retrieving and installing >>Perl modules? >> >>I need some guidance on how it is supposed to work. > >In theory you give it the module you want installed and go and make the tea. In >practise on OS/2 it usually goes wrong :-( I find it easier to go FTP what I >need. Where the CPAN thing pays off is where you need tons of packages that all >cross relate to get some feature or other installed. But as I said that is when >it usually fails. I would think on *nix it is pretty solid. I had this working as part of an experimental UX2 build system once. As I recall, it was just a matter of adding lines to the build_perl.cmd to install the CPAN module, then copy in a pre-configured config.pm (no worse than having to patch other things), and then running lines like perl -MCPAN -e install CGI so that you ended up with a perl complete with some useful modules. ISTR that this worked as well on OS/2 as it does on other platforms. >-- >Regards > >Dave Saville > > > - Lyn **= Email 10 ==========================** Date: Thu, 30 Jun 2005 20:32:51 +0100 From: John Poltorak Subject: Re: The OS/2 and eCS Ecosystem On Thu, Jun 30, 2005 at 07:35:40PM +0200, Stefan.Neis at t-online.de wrote: > Dave Yeo schrieb: > > > I think the only place that ASH is hardwired > > is a %MAKESHELL% and %CONFIG_SHELL% in > > setmozenv.cmd. Anyways what is wrong > > with using ASH as the makeshell? > > It's broken in some of the more esoteric areas > (i.e. not quite conforming to current POSIX > standard). wxWidgets currently has a > work-around in it's build system to make > everything work with ash under OS/2 (that way > configure runs about 20% faster), but if you > now run the scripts under (pd)ksh, some of > the generated scripting code is broken - and > repairing it for (pd)ksh or any other standard > conforming shell is going to break it for ash. Are you saying that you need ASH to be able to build wxWidgets and that PDKSH is useless for this task unless you manually change some of the scripting? I'd change UX2BS to use ASH but it doesn't work any way and I don't think Perl will build with it. As far as ASH goes, has anyone taken over maintenance of it? And are there still several versions of it in general use? > Regards, > Stefan -- John **= Email 4 ==========================** Date: Thu, 30 Jun 2005 20:44:30 +0100 From: John Poltorak Subject: Re: The OS/2 and eCS Ecosystem On Thu, Jun 30, 2005 at 07:56:13AM -0700, billn wrote: > I'm planning on working with the GCC 3.3.5b5 when I get some time. Right > now my FreeBSD system is down, my W2KServer is misbehaving and won't > recognize the new 250 GB drive, and my security system needs to be built > and installed. > > So it will be a while. I'll let you know when I work on it. Right now UX2BS does not use gcc v3.3.5, it is built around v2.8.1 but installing UX2BS is pretty straightforward and only takes a couple of minutes as it is a fully automated install process which actually builds parts of build system as it installs itself. In due course I hope to incorporate the latest version of gcc but that is still some time away. > BillN > > John Poltorak wrote: > > > > On Sun, Jun 26, 2005 at 07:55:09AM -0700, billn wrote: > > > > > The kicker in all of this is getting more developers on board. In > > > particular, if we had an easy to install development environment that > > > would install on OS/2 *or* Linux, we could invite Linux developers to > > > build OS/2 versions of their current applications, and have the ability > > > to build custom applications w/o having to spend large amounts of time > > > in the install and tuning of a development tool. > > > > Have you ever tried installing UX2BS? > > > > > BillN > > > > -- > > John -- John **= Email 11 ==========================** Date: Thu, 30 Jun 2005 22:09:43 +0200 From: "Knut St. Osmundsen" Subject: Re: The OS/2 and eCS Ecosystem John Poltorak wrote: > On Thu, Jun 30, 2005 at 07:35:40PM +0200, Stefan.Neis at t-online.de wrote: > >>Dave Yeo schrieb: >> >> >>>I think the only place that ASH is hardwired >>>is a %MAKESHELL% and %CONFIG_SHELL% in >>>setmozenv.cmd. Anyways what is wrong >>>with using ASH as the makeshell? >> >>It's broken in some of the more esoteric areas >>(i.e. not quite conforming to current POSIX >>standard). wxWidgets currently has a >>work-around in it's build system to make >>everything work with ash under OS/2 (that way >>configure runs about 20% faster), but if you >>now run the scripts under (pd)ksh, some of >>the generated scripting code is broken - and >>repairing it for (pd)ksh or any other standard >>conforming shell is going to break it for ash. > > > Are you saying that you need ASH to be able to build wxWidgets and that > PDKSH is useless for this task unless you manually change some of the > scripting? > > I'd change UX2BS to use ASH but it doesn't work any way and I don't think > Perl will build with it. > > As far as ASH goes, has anyone taken over maintenance of it? And are there > still several versions of it in general use? I've meant to get it up to date with the current FreeBSD version for a long time now but haven't gotten around to it yet. The ash version I'm currently using for gcc et al is contains a couple of new hacks and since early fork development has been build using libc (it was the 2nd fork() milestone actually). Kind Regards, knut **= Email 5 ==========================** Date: Thu, 30 Jun 2005 22:13:29 +0200 From: Andreas Buening Subject: make 3.81 Beta 3 Hi, all! A new GNU make 3.81 beta version has been released which will (hopefully) lead to a release soon(er or later). Some internals have changed, especially for Posix conformance. Thus, the maintainer suggests to test especially the non-Unix ports, so if you have too much spare time ... :-) I've just changed some very minor things. If you run the testsuite, only 5 tests fail which might be an error of the testsuite and 1 fails if you use ksh as /bin/sh (seems to be an OS/2-related "feature" of ksh). You find a binary release at http://unix.os2site.com/sw/pub/binary/make/make-3.81beta3-bin.zip and the sources at http://unix.os2site.com/sw/pub/source/make/make-3.81beta3.zip The unmodified sources can be found at ftp://alpha.gnu.org/gnu/make/ Btw, some .m4 files are still missing in the make source package, so you have to use the enclosed configure and you can't use autoconf/automake. Bye, Andreas **= Email 12 ==========================** Date: Thu, 30 Jun 2005 22:31:24 +0100 From: John Poltorak Subject: Re: The OS/2 and eCS Ecosystem On Thu, Jun 30, 2005 at 10:09:43PM +0200, Knut St. Osmundsen wrote: > > > John Poltorak wrote: > > I'd change UX2BS to use ASH but it doesn't work any way and I don't think > > Perl will build with it. > > > > As far as ASH goes, has anyone taken over maintenance of it? And are there > > still several versions of it in general use? > > I've meant to get it up to date with the current FreeBSD version for a > long time now but haven't gotten around to it yet. The ash version I'm > currently using for gcc et al is contains a couple of new hacks and > since early fork development has been build using libc (it was the 2nd > fork() milestone actually). Where is the latest version of ASH? Should I expect to be able to use it as a drop in replacement for PDKSH? If not, what would I need to change? > Kind Regards, > knut -- John **= Email 6 ==========================** Date: Fri, 01 Jul 2005 00:01:16 +0200 From: Andreas Buening Subject: Re: The OS/2 and eCS Ecosystem Dave Yeo wrote: > Dave, who is willing to give any help I can to help you setup a build enviroment, but is > always short on time billn wrote: > I'm an example of a programmer who likes to work on applications, but > does not want to spend time working on infrastructure. I think you both are not the only ones who like to work on applications, not infrastructure or who are willing to help but don't know why. What about the following idea? There are many base "infrastructure" software packages. Every few days there is a new release of one of them. After some weeks or month an OS/2 developer detects "oh, there is a new version", downloads, tries to compile but there are some issues which prohibit building that package out of the box. Often, these errors are just minor things like a missing include file. So the developer fixes this and sends his patches to the maintainers. But when the next version is released, several other changes were made and this time the build fails because $PATH was not sufficiently quoted for OS/2. So the same cycle starts again but the "official" releases often don't work because they are tested by the OS/2 community _after_ the release. My suggestion would be that you or other people who have at least basic programming knowledge "adopt" one or two of these packages in the sense that you subscribe to the package-specific mailing list (if there is any) or tell the maintainers that you would like to be informed when a new release is about to happen. If a new release candidate comes out you download and try to build it. If there is just a missing header, you can fix it yourself. If it's more complicated, you can tell the maintainers that you get the error message xy on OS/2, or you ask on this mailing list whether anybody else could help. Then, we could be sure that the official releases will work on OS/2 out of the box because they were tested on OS/2 _before_ their release. Many packages show no activity for months. Thus, I think we are talking of at most four hours per month and much less in "inactive" months depending on how much spare time you would be willing to spend. :-) However, to get a fully functional out of the box installation system for all important Unix apps, we need more than just a few packages, or even more than just all packages: we need some kind of organization. What do I mean by this? Consider a developer who ports an application to OS/2 that he wants to add to the (not existing) UnixOS/2 distribution. He has - to patch the sources and compile them the to get binaries - to package these binaries into an installable package - to decide whether that package version is stable enough to be included into the UnixOS/2 distro - to put the package into the installation tree of the distro and to update its internal setup files - to write some html or whatever document that informs how the package could be compiled, what are its restrictions for OS/2, its known bugs and so on Every part of this pipe is as important as any other because if one part is missing we'll never get a distro which is easy to install. Somebody who doesn't have any programming knowledge is obviously not the best choice to port an application. For the same reason a developer is not the best choice to write web pages and to setup installation trees because he a) thinks that porting apps is more important than to make an installation system (he's a developer, so what did you think is important for him, of course?) so that he will often "skip" those tasks if he's short on time, and b) he may not know how a new package is added to the distro, or c) he even thinks that nobody needs a installable distro because everything is easy to him. (At this point I apologize to all developers who like to write html pages and to build distros.) So let the developers do what they do best: porting apps. And let other people do all the other stuff which is exactly as necessary as porting apps if you want to have an installable UnixOS/2 distro. E.g., John has done a lot of research how to setup a distro so I think he would be most suited to turn a collection of single packages into a distro. So we need developers as much as people who keep the web page up to date, who write some docs about our packages (how to compile them, how to use them, what are their restrictions), who don't hesitate to ask when they don't understand something, who tell about duplicate links which point to wrong or outdates pages, who are willing to do beta tests sometimes (you really don't need any programming experience for that), who work self-dependent and don't hesitate to nudge (kindly) other people when they did their contribution but are waiting for more input. Otherwise everything will sooner or later fall again to sleep because people are waiting on each other. If we can't come to some "organizational" structure where several levels of the "distribution build process" are working independently and where are people who are "driving" (or better: motivating) other people, nothing will happen on the long term. So, do we have any volunteers? :-))) Bye, Andreas **= Email 13 ==========================** Date: Thu, 30 Jun 2005 16:28:33 -0700 From: billn Subject: Re: The OS/2 and eCS Ecosystem I think the base problem is probably organization. But: Why not use FreeBSD ports, adjusted for OS/2? The code is available, and it includes build directives which get customized for each application. This would get around the problem of old and new apps needing different environments, since the ports system handles that. I'm a fan of FreeBSD ports and have built many on my FreeBSD system. I think that this approach avoids the pitfalls of finding a universal setup and makes the porting process easier, which should increase the number of people doing ports. Comments? BillN Andreas Buening wrote: > > Dave Yeo wrote: > > > Dave, who is willing to give any help I can to help you setup a build enviroment, but is > > always short on time > > billn wrote: > > > I'm an example of a programmer who likes to work on applications, but > > does not want to spend time working on infrastructure. > > I think you both are not the only ones who like to work on applications, > not infrastructure or who are willing to help but don't know why. > > What about the following idea? > > There are many base "infrastructure" software packages. Every few days there > is a new release of one of them. After some weeks or month an OS/2 developer > detects "oh, there is a new version", downloads, tries to compile but there > are some issues which prohibit building that package out of the box. > Often, these errors are just minor things like a missing include file. > So the developer fixes this and sends his patches to the maintainers. > But when the next version is released, several other changes were made > and this time the build fails because $PATH was not sufficiently quoted > for OS/2. So the same cycle starts again but the "official" releases > often don't work because they are tested by the OS/2 community _after_ > the release. > > My suggestion would be that you or other people who have at least basic > programming knowledge "adopt" one or two of these packages in the sense > that you subscribe to the package-specific mailing list (if there is any) > or tell the maintainers that you would like to be informed when a new > release is about to happen. If a new release candidate comes out > you download and try to build it. If there is just a missing header, > you can fix it yourself. If it's more complicated, you can tell the > maintainers that you get the error message xy on OS/2, or you ask on > this mailing list whether anybody else could help. Then, we could be > sure that the official releases will work on OS/2 out of the box because > they were tested on OS/2 _before_ their release. > > Many packages show no activity for months. Thus, I think we are talking > of at most four hours per month and much less in "inactive" months > depending on how much spare time you would be willing to spend. :-) > > However, to get a fully functional out of the box installation system > for all important Unix apps, we need more than just a few packages, or > even more than just all packages: we need some kind of organization. > What do I mean by this? Consider a developer who ports an application > to OS/2 that he wants to add to the (not existing) UnixOS/2 distribution. > He has > - to patch the sources and compile them the to get binaries > - to package these binaries into an installable package > - to decide whether that package version is stable enough to be included > into the UnixOS/2 distro > - to put the package into the installation tree of the distro and to update > its internal setup files > - to write some html or whatever document that informs how the package > could be compiled, what are its restrictions for OS/2, its known bugs > and so on > > Every part of this pipe is as important as any other because if one part > is missing we'll never get a distro which is easy to install. > > Somebody who doesn't have any programming knowledge is obviously not > the best choice to port an application. For the same reason a developer > is not the best choice to write web pages and to setup installation trees > because he a) thinks that porting apps is more important than to make > an installation system (he's a developer, so what did you think is > important for him, of course?) so that he will often "skip" those tasks if > he's short on time, and b) he may not know how a new package is added to > the distro, or c) he even thinks that nobody needs a installable distro > because everything is easy to him. (At this point I apologize to all > developers who like to write html pages and to build distros.) > > So let the developers do what they do best: porting apps. And let other > people do all the other stuff which is exactly as necessary as porting > apps if you want to have an installable UnixOS/2 distro. E.g., John has > done a lot of research how to setup a distro so I think he would be > most suited to turn a collection of single packages into a distro. > > So we need developers as much as people who keep the web page up to date, > who write some docs about our packages (how to compile them, how to use them, > what are their restrictions), who don't hesitate to ask when they don't > understand something, who tell about duplicate links which point to > wrong or outdates pages, who are willing to do beta tests sometimes (you > really don't need any programming experience for that), who work > self-dependent and don't hesitate to nudge (kindly) other people > when they did their contribution but are waiting for more input. Otherwise > everything will sooner or later fall again to sleep because people are > waiting on each other. If we can't come to some "organizational" structure > where several levels of the "distribution build process" are working > independently and where are people who are "driving" (or better: motivating) > other people, nothing will happen on the long term. > > So, do we have any volunteers? :-))) > > Bye, > Andreas **= Email 7 ==========================** Date: Fri, 1 Jul 2005 01:51:19 +0100 From: John Poltorak Subject: Re: The OS/2 and eCS Ecosystem Andreas, It's nice to see you post on this list again. It seems almost inevitable that everyone will give up on OS/2 eventually so it isn't surprising when people stop pposting... but it's nice to have a few 'old-timers' who keep coming back. On Fri, Jul 01, 2005 at 12:01:16AM +0200, Andreas Buening wrote: > Dave Yeo wrote: > > > Dave, who is willing to give any help I can to help you setup a build enviroment, but is > > always short on time > > > billn wrote: > > > I'm an example of a programmer who likes to work on applications, but > > does not want to spend time working on infrastructure. > > > I think you both are not the only ones who like to work on applications, > not infrastructure or who are willing to help but don't know why. > > What about the following idea? > > There are many base "infrastructure" software packages. Every few days there > is a new release of one of them. After some weeks or month an OS/2 developer > detects "oh, there is a new version", downloads, tries to compile but there > are some issues which prohibit building that package out of the box. > Often, these errors are just minor things like a missing include file. > So the developer fixes this and sends his patches to the maintainers. > But when the next version is released, several other changes were made > and this time the build fails because $PATH was not sufficiently quoted > for OS/2. So the same cycle starts again but the "official" releases > often don't work because they are tested by the OS/2 community _after_ > the release. > > My suggestion would be that you or other people who have at least basic > programming knowledge "adopt" one or two of these packages in the sense > that you subscribe to the package-specific mailing list (if there is any) > or tell the maintainers that you would like to be informed when a new > release is about to happen. If a new release candidate comes out > you download and try to build it. What is required is a standard build environment otherwise a particular package's maintainer will be the only one capable of building it. > If there is just a missing header, > you can fix it yourself. If it's more complicated, you can tell the > maintainers that you get the error message xy on OS/2, or you ask on > this mailing list whether anybody else could help. Then, we could be > sure that the official releases will work on OS/2 out of the box because > they were tested on OS/2 _before_ their release. > > Many packages show no activity for months. Thus, I think we are talking > of at most four hours per month and much less in "inactive" months > depending on how much spare time you would be willing to spend. :-) > > > However, to get a fully functional out of the box installation system > for all important Unix apps, we need more than just a few packages, or > even more than just all packages: we need some kind of organization. > What do I mean by this? Consider a developer who ports an application > to OS/2 that he wants to add to the (not existing) UnixOS/2 distribution. > He has > - to patch the sources and compile them the to get binaries > - to package these binaries into an installable package > - to decide whether that package version is stable enough to be included > into the UnixOS/2 distro > - to put the package into the installation tree of the distro and to update > its internal setup files > - to write some html or whatever document that informs how the package > could be compiled, what are its restrictions for OS/2, its known bugs > and so on > > Every part of this pipe is as important as any other because if one part > is missing we'll never get a distro which is easy to install. > > Somebody who doesn't have any programming knowledge is obviously not > the best choice to port an application. For the same reason a developer > is not the best choice to write web pages and to setup installation trees > because he a) thinks that porting apps is more important than to make > an installation system (he's a developer, so what did you think is > important for him, of course?) so that he will often "skip" those tasks if > he's short on time, and b) he may not know how a new package is added to > the distro, or c) he even thinks that nobody needs a installable distro > because everything is easy to him. (At this point I apologize to all > developers who like to write html pages and to build distros.) > > So let the developers do what they do best: porting apps. This isn't strictly true. Sometimes developers make a rod for their own backs because of an inadequate infrastructure or lack of understanding of the Unix build process. They introduce code to compensate for deficiencies in their build environment whereas the correct tools might obviate the need for any code changes. The biggest waste of effort is in coming up with ways to 'convert' a configure into being OS/2 friendly instead of addressing why the configure script was incorrect in the first place. I'm still trying to figure out how many of the patches in GNU file/text/shell utils in Jun Sawataishi's ports would be necessary if autoconf was used instead of his configure converter. > And let other > people do all the other stuff which is exactly as necessary as porting > apps if you want to have an installable UnixOS/2 distro. E.g., John has > done a lot of research how to setup a distro so I think he would be > most suited to turn a collection of single packages into a distro. I have done a lot of work in trying to set up a standard build environment and much of that work centres around your unappreciated efforts to update things like automake, autoconf and make which people are generally unaware of but which make possible the building of numerous apps almost staraight out of the box without any code changes. What I'd really like is for you to have a look at UX2BS and see how it can be used as a general purpose framework for building apps on OS/2. It is basically modelled on the GNU build system but attempts to handle exceptions to the standard build process. Once that build system is in place and accepted as the standard build framework it will allow porters to be far more productive as they will be able to concentrate on code rather than infrastructure. > So we need developers as much as people who keep the web page up to date, > who write some docs about our packages (how to compile them, how to use them, > what are their restrictions), who don't hesitate to ask when they don't > understand something, who tell about duplicate links which point to > wrong or outdates pages, who are willing to do beta tests sometimes (you > really don't need any programming experience for that), who work > self-dependent and don't hesitate to nudge (kindly) other people > when they did their contribution but are waiting for more input. Otherwise > everything will sooner or later fall again to sleep because people are > waiting on each other. If we can't come to some "organizational" structure > where several levels of the "distribution build process" are working > independently and where are people who are "driving" (or better: motivating) > other people, nothing will happen on the long term. > > So, do we have any volunteers? :-))) I'll volunteer to work on the infrastructure although I'd like your help with it. > Bye, > Andreas -- John **= Email 14 ==========================** Date: Fri, 1 Jul 2005 02:00:19 +0100 From: John Poltorak Subject: Re: The OS/2 and eCS Ecosystem On Thu, Jun 30, 2005 at 04:28:33PM -0700, billn wrote: > I think the base problem is probably organization. > > But: Why not use FreeBSD ports, adjusted for OS/2? Are you going to port it? > The code is available, and it includes build directives which get > customized for each application. This would get around the problem of > old and new apps needing different environments, since the ports system > handles that. I've looked a few BSD makefiles and can't make head nor tail of them > I'm a fan of FreeBSD ports and have built many on my FreeBSD system. Such as... > I think that this approach avoids the pitfalls of finding a universal > setup > and makes the porting process easier, which should increase the number > of people doing ports. We have plenty of ports - it's just that many of them don't work together very well. What we need is a standard infrastructure. > Comments? > > BillN -- John **= Email 8 ==========================** Date: Thu, 30 Jun 2005 22:38:45 -0800 From: "Dave Yeo" Subject: Re: CPAN On Thu, 30 Jun 2005 17:16:14 +0100, John Poltorak wrote: >This the first time I've used Perl on this system so the CPAN >configuration will need initialising and as with all manual setups it is >error prone. Should I go for all the defaults? Is there a log of setting >it up so that I can refer to it subsequently? Wonder if there is a way to >set it up automatically... I usually just go for the defaults but I have not had very good luck with CPAN so the few things I've needed I've done manually. eg I tried with ux2bs today and Term:readline failed 1/4 tests and ended up with make.exe: *** [test_dynamic] Error 255 g:/usr/bin/make.exe test -- NOT OK Running make install make test had returned bad status, won't install without force Not sure how to use force and don't have enough time right now to research it. Also using ux2bs CPAN keeps freezing on me. > >Something has got screwed up anyway so I need to start again, not sure >what happens in the case of an incomplete configuration... Delete /home/root/.cpan Dave **= Email 15 ==========================** Date: Fri, 1 Jul 2005 09:24:29 +0200 From: "mentore\.siesto\ at libero\.it" Subject: Re: The OS/2 and eCS Ecosystem ---------- Initial Header ----------- From : owner-os2-unix at warpix.org To : os2-unix at mail.warpix.org Cc : Date : Fri, 01 Jul 2005 00:01:16 +0200 Subject : Re: The OS/2 and eCS Ecosystem > I think you both are not the only ones who like to work on applications, > not infrastructure or who are willing to help but don't know why. I come out of my long-sleeping time to agree with you. > Many packages show no activity for months. Thus, I think we are talking > of at most four hours per month and much less in "inactive" months > depending on how much spare time you would be willing to spend. :-) Right. > So let the developers do what they do best: porting apps. And let other > people do all the other stuff which is exactly as necessary as porting > apps if you want to have an installable UnixOS/2 distro. E.g., John has > done a lot of research how to setup a distro so I think he would be > most suited to turn a collection of single packages into a distro. > So, do we have any volunteers? :-))) There's also the need to co-ordinate all these efforts. So, we should setup a sort of hierarchy, with someone who says "Hey, it's OK for me to write web pages" and another one who answers "Ok, so the packages blurb, foo, dummy, moe and curly are your job, while you will work on documentation for blah, blablah and zipzap" **= Email 9 ==========================** Date: Fri, 1 Jul 2005 09:42:28 +0100 From: John Poltorak Subject: Re: CPAN On Thu, Jun 30, 2005 at 10:38:45PM -0800, Dave Yeo wrote: > On Thu, 30 Jun 2005 17:16:14 +0100, John Poltorak wrote: > > >This the first time I've used Perl on this system so the CPAN > >configuration will need initialising and as with all manual setups it is > >error prone. Should I go for all the defaults? Is there a log of setting > >it up so that I can refer to it subsequently? Wonder if there is a way to > >set it up automatically... > > I usually just go for the defaults but I have not had very good luck with CPAN so the few things I've needed I've done manually. eg I tried with ux2bs today and Term:readline failed 1/4 tests and ended up with > make.exe: *** [test_dynamic] Error 255 > g:/usr/bin/make.exe test -- NOT OK > Running make install > make test had returned bad status, won't install without force You would probably use CPAN extensively if it worked correctly because there is so much Perl stuff around and this provides the perfect system for retrieving and installing Perl modules. It would be great to have a UnixOS/2 equivalent one day. You say you used UX2BS but it is a moving target and does get updated from time to time. Which version of Perl do you have? > Not sure how to use force and don't have enough time right now to research it. > Also using ux2bs CPAN keeps freezing on me. I tried it again yesterday and did eventually get CPAN configured and retrieving Perl modules, but they were getting corrupted for some reason. > > > >Something has got screwed up anyway so I need to start again, not sure > >what happens in the case of an incomplete configuration... > > Delete /home/root/.cpan The setup appears to be done by the module /CPAN/FistTime.pm although I'm useless with Perl and can't figure out the nitty gritty although it looks like CPAN will be autoconfigured if you don't want to go through the dialog. It may be an idea to set up a generic configuration file for ux2bs > Dave -- John **= Email 10 ==========================** Date: Fri, 01 Jul 2005 11:19:09 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: The OS/2 and eCS Ecosystem John Poltorak schrieb: > Are you saying that you need ASH to be able > to build wxWidgets and that PDKSH is useless > for this task unless you manually change > some of the scripting? No. The problem is that the build process is supposed to generate two scripts for building DLLs (so it's DDL build only that's affected, anyway), and because of said problem the scripts are currently contained in the distribution. BTW, the "dllar.sh" seems to be quite stable, currently, I guess I should send that to Knut for inclusion in gcc distribution, thus solving half of the problem ... ;-) Regards, Stefan > > I'd change UX2BS to use ASH but it doesn't work any way > and I don't think > Perl will build with it. > > As far as ASH goes, has anyone taken over maintenance of > it? And are there > still several versions of it in general use? > > > Regards, > > Stefan > > > -- > John > > > **= Email 16 ==========================** Date: Fri, 01 Jul 2005 11:27:40 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: The OS/2 and eCS Ecosystem Andreas Buening schrieb: (snipp) > If a new release candidate comes out > you download and try to build it. If there > is just a missing header, you can fix it > yourself. If it's more complicated, you > can tell the maintainers that you get the > error message xy on OS/2, or you ask on > this mailing list whether anybody else could > help. Then, we could be sure that the > official releases will work on OS/2 out of > the box because they were tested on OS/2 > _before_ their release. (snipp) > I think we are talking of at most four > hours per month and much less in "inactive" > months (snipp) Note however that this sounds easier than it actually is, because you typically need to find those four hours within a rather small part of the month, i.e. delaying the release because you just have no time at all for the next week to test if it works on OS/2 as well, will often _not_ work. :-( Regards, Stefan