From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 29 Nov 2003 14:16:09 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 255 ************************************************** Friday 28 November 2003 Number 255 ************************************************** Subjects for today 1 Re: UnixOS/2 distro (documentation) : Jeff Robinson 2 Re: UnixOS/2 distro : T.Sikora" 3 Re: UnixOS/2 distro : T.Sikora" 4 UnixOS/2 distro : Andreas Buening 5 Re: UnixOS/2 distro : John Poltorak 6 Re: UnixOS/2 distro : Andreas Buening 7 Re: UnixOS/2 distro (documentation) : Andreas Buening 8 Re: UnixOS/2 distro : Andreas Buening 9 Re: UnixOS/2 distro : John Poltorak **= Email 1 ==========================** Date: Sat, 29 Nov 2003 11:11:04 -0600 From: Jeff Robinson Subject: Re: UnixOS/2 distro (documentation) Andreas Buening wrote: > Hello! > > The development of an UnixOS/2 distribution hasn't really proceeded > during the last year, mostly due to lack of time of most of us. > However, John is back, and maybe we can push things up. :-) > > > 5. Documentation > > Someone who writes html-pages. (Jeff?) > Everytime task 4 leads to a new package or to a new version of > a package, someone has to document this. I could imagine some > web structure like this: > > [The main page] > - Installing UnixOS/2 -> link to the install page > - The UnixOS/2 packages -> link to the package page > - Environment variables -> link ... > - Known problems -> link ... > - FAQ -> ... > - TODO list (e.g., which package needs a maintainer) -> ... > > I've never seen a site where all possible env. vars. are documented, > but if we could do this it would be great. > > [The main package page] > - a2ps -> link to a2ps > - autoconf -> ... > ... > - zope -> ... > > > Finally a package page could look as follows: > > [webpage of foo] > - foo x.y: Short description what this tool is doing > - Env. vars. used by foo -> link to the env. var. page > - current status of foo on OS/2, restrictions? > - How to build foo: -> either link to the standard build scheme > page, or a description what to do otherwise > - Information about old releases of foo > > Hi Andreas, I don't know if it is some sort've synchronicity or what, but I've been actually working on getting the UnixOS2 pages back into shape and up to date. As of yesterday I've got a new "framework" for the site in place... the biggest change being that the list of packages now link to an individual page for each package where we can then put as much information as we wish. Each package page will also contain links to pages/topics relevant to that piece of software. Right now I'm just trying to get my PPWizard scripts into shape so that it'll automatically generate pages for each package... I'm hoping to have a lot of that cleaned up by the end of today. (It's amazing what a Canadian winter does for indoor productivity!) I've been having some thoughts about the packages in general, but I'll leave that to another letter so as to not get too many threads going in one place. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 2 ==========================** Date: Sat, 29 Nov 2003 17:23:54 -0500 From: "T.Sikora" Subject: Re: UnixOS/2 distro Andreas Buening wrote: > IanM wrote: > > [snip] > > >>Happy to maintain it, also happy for Ted to maintain it and I'll simply >>mirror it, it sort of depends, Ted is probably like me, if the original is >>on os2ports the Ted, if the original is on unixos2.com then me, unixos2.com >>is ment to be the home of it though, or at least the final resting place. > > > Unfortunately, I don't know what's the difference between unixos2.com > and os2ports? Does any of the servers have more total storage, larger > bandwidth? Otherwise it doesn't matter which one is the main > server as long as Ted and you agree. > > Actually os2ports has nothing to do with unixos2.com anymore. It was just a temporary home till unixos2.com got sorted out. -- T.Sikora tsikora at ntplx dot net **= Email 3 ==========================** Date: Sat, 29 Nov 2003 17:27:47 -0500 From: "T.Sikora" Subject: Re: UnixOS/2 distro T.Sikora wrote: > Andreas Buening wrote: > >> IanM wrote: >> >> [snip] >> >> >>> Happy to maintain it, also happy for Ted to maintain it and I'll simply >>> mirror it, it sort of depends, Ted is probably like me, if the >>> original is >>> on os2ports the Ted, if the original is on unixos2.com then me, >>> unixos2.com >>> is ment to be the home of it though, or at least the final resting >>> place. >> >> >> >> Unfortunately, I don't know what's the difference between unixos2.com >> and os2ports? Does any of the servers have more total storage, larger >> bandwidth? Otherwise it doesn't matter which one is the main >> server as long as Ted and you agree. >> >> > > Actually os2ports has nothing to do with unixos2.com anymore. It was > just a temporary home till unixos2.com got sorted out. > .. and it's suffering a serious case of neglect too. Probably the only thing you can rely on is the /os2/unix/devtools being current. -- T.Sikora tsikora at ntplx dot net **= Email 4 ==========================** Date: Sat, 29 Nov 2003 17:53:29 +0100 From: Andreas Buening Subject: UnixOS/2 distro Hello! The development of an UnixOS/2 distribution hasn't really proceeded during the last year, mostly due to lack of time of most of us. However, John is back, and maybe we can push things up. :-) If I recall many threads of the last months, then there were numerous problems like "a compiles fine with gcc x.x while b compiles with gcc y.y, now I need library c, but the version of c that is released with gcc z.z doesn't work unless I use the linker of gcc x.x. Then it compiles but the program crashes. However, library d also contains library c but the linker of gcc y.y doesn't find some symbols. Library e which works great with f doesn't have feature g and the headers of package h clash with gcc y.y but not if library i has been installed ... John, you seem to be incredibly patient. ;-) If people ask "I want to compile foo but it doesn't work because of xyz, what can I do?" then the anwer is "it depends". It depends on compilers, libraries, installed tools, . But the anwer must be "Install the UnixOS/2 distro and that's it". One really big problem is that the number of problems like different libraries or gcc versions doesn't decrease but increase instead. We have been waiting for years to get a full featured gcc and build environment but there have been and still are countless numbers of problems, workarounds and whatever (at least, that's my impression). Thanks to John's and other contributors' great work we have mostly everything we need for a "core" release. And I think the best way to proceed will be to make a "stable" release of the "core" tools which then defines _the_ standard and can be installed by everyone. For this we need: 1. Technical infrastructure A server on which we can store the sources, binaries and everything else of the UnixOS/2 distro. We already have this (unixos2, os2site). Which one do we finally want to use? A useful directory structure (.../unixos2/0.1-stable, .../unixos2/0.1-beta, ...) and a maintainer for it (Ted, Ian?). FTP access for package maintainers so that they can modify their own stuff. An incoming directory for small contributions. 2. Distribution maintainance After a package maintainer has uploaded his new source (and binary) release, we need someone who arranges the package in the UnixOS/2 tree (not every package maintainer can know what belongs to which place), recompiles the package if necessary, creates the PKGINFO files, decides when the new UnixOS/2 beta reaches stable status, and so on. (John?) 3. Installation tools A big issue are the installation and administration tools. We already have some but they are still incomplete. Micheal, if you're reading, could you provide some information about, which tool does what, and, even more important, provide some comments for the rexx files? Without comments the code isn't really helpful. ;-) These tools must have a simple interface, be absolutely bulletproof, fast and fully reliable. Which means this task is absolutely not simple. ;-) For the final implementation, I guess, we need some database which contains all the package info, so that it is not necessary to browse hundreds of single PKGINFO files when installing another package. The access to this database can be written in rexx (from scratch) or we could use other (simple) tools like perl, python, whatever. However, the first "stable" release of these installation tools doesn't need to have all desired features but it must be reliable and compatible to future versions. Without these tools we'll never have a UnixOS/2 distro which can be installed "out of the box". 3. Package maintainance We need people who maintain packages. This can mean writing and submitting patches for OS/2. For packages which are already working it can just mean to keep listening to the responsible mailing list of that package, compile new releases and check whether it still works. For this task you wouldn't even need to know anything about programming. The package maintainer should do the following: - Listen to the mailing list of that package - Download, compile and test new releases for OS/2 - Write and submit patches if necessary - Upload the tested sources to the UnixOS/2 server - Upload the compiled binaries to the UnixOS/2 server - Create PKGINFO files If any maintainer doesn't want or isn't able to do some of these steps then someone else (e.g., the disto maintainer) has to complete this job for every release of this specific package. 4. Overall organization We need someone who does what John is currently doing: Integrate new packages into the ux2 system. - Finding packages which should be part of ux2 - Finding problems with these packages - Solving these problems (or finding someone who solves them) - (!) Keeping track of what is going on, which package has reached which status, what is on top of the todo list ... - Convincing other people to contribute their packages to the ux2 system 5. Documentation Someone who writes html-pages. (Jeff?) Everytime task 4 leads to a new package or to a new version of a package, someone has to document this. I could imagine some web structure like this: [The main page] - Installing UnixOS/2 -> link to the install page - The UnixOS/2 packages -> link to the package page - Environment variables -> link ... - Known problems -> link ... - FAQ -> ... - TODO list (e.g., which package needs a maintainer) -> ... I've never seen a site where all possible env. vars. are documented, but if we could do this it would be great. [The main package page] - a2ps -> link to a2ps - autoconf -> ... ... - zope -> ... Finally a package page could look as follows: [webpage of foo] - foo x.y: Short description what this tool is doing - Env. vars. used by foo -> link to the env. var. page - current status of foo on OS/2, restrictions? - How to build foo: -> either link to the standard build scheme page, or a description what to do otherwise - Information about old releases of foo One single person usually can't do all of the points above for his package, due to missing spare time and also due to missing knowledge how, why and where is which subprocess organized. To summarize my thoughts, how I think the organization should work: - (4) The main organizator (e.g. John) wants to add a new package to ux2 (e.g. gawk) but something doesn't work. Then he contacts the maintainer of that package. In this case this would be me. - (3) The maintainer now fixes the problem and uploads the patched sources to our server (.../unixos2/sources/gawk/gawk-x_y.zip). If he knows, how to to this, he can also compile the code and create a ready-to-install package (.../unixos2/binaries/gawk/gawk-x_y-bin.zip). - (5) As soon as gawk works, the person who is responsible for the docs puts the result onto our website. He shouldn't hesitate to bother the maintainer or other people until he has all the information he needs. - (2) The distribution maintainer decides which version of gawk is stable enough to be put into the stable release or just into the next beta (.../unixos2/0.1-stable/a1/gawk.zip). Since we have so (too) many different gcc releases, libraries with/without features like fork and friends, I suggest the following: We create a gcc-2_8_1 package which will be installed into /usr/local/appl/gcc-2_8_1. It will be called by a gcc-2_8_1.cmd script somewhere in the path, i.e., by setting CC=gcc-2_8_1 before calling ./configure. Why? Because 2.8.1 is the last real emx release, it doesn't have any fork/socket/whatever problems, no gcc*.dll, no other funny stuff. It can serve as reference for compiling packages. If anything works with 2.8.1 but not with newer versions then it has to be considered as a bug and has to be fixed. I also suggest to compile all programs of the UnixOS/2 distro 0.1 by using 2.8.1, just to have a standard. Programs which need newer gcc versions (e.g. C++ programs) don't make it into release 0.1 stable but can be put into 0.2 beta. It's just to keep the "core" release 0.1 clean. Does this sound reasonable to you? Bye, Andreas P.S.: I apologize to you for this far too long email. **= Email 5 ==========================** Date: Sat, 29 Nov 2003 19:30:42 +0000 From: John Poltorak Subject: Re: UnixOS/2 distro On Sat, Nov 29, 2003 at 05:53:29PM +0100, Andreas Buening wrote: > Hello! > > The development of an UnixOS/2 distribution hasn't really proceeded > during the last year, mostly due to lack of time of most of us. > However, John is back, and maybe we can push things up. :-) > > If I recall many threads of the last months, then there were numerous > problems like "a compiles fine with gcc x.x while b compiles with > gcc y.y, now I need library c, but the version of c that is released > with gcc z.z doesn't work unless I use the linker of gcc x.x. Then > it compiles but the program crashes. However, library d also contains > library c but the linker of gcc y.y doesn't find some symbols. > Library e which works great with f doesn't have feature g and > the headers of package h clash with gcc y.y but not if library i > has been installed ... > John, you seem to be incredibly patient. ;-) The problem with different people building different apps and no one else being able to build them is because there is no standard build environment. This is where UX2BS comes in. I am in the process of developing a build system which start off with a very old basic set of standard utils and produces a build framework which allows a large number of apps to get built in a standardised way just by running build APPNAME This is something I would very much like you to try out, because with a little input from you the system could accelerate pretty quickly and become very much more functional. Your work with the Autotools has made many GNU app relatively easy to build. I think that many others could also get built with minor changes to configure.in and Makefile.am and you seem to be the leading expert in that area. If you have an opportunity to do so could you try running this:- ? wget ftp://unixos2: at 213.152.37.92/pub/unixos2/build_system/lib/ux2_bootstrap.cmd followed by the retrieved ux2_bootstrap.cmd It is best installed on a free partition if possible, althoug if you don't have a fast link it may be difficult to do. > If people ask "I want to compile foo but it doesn't work > because of xyz, what can I do?" then the anwer is "it depends". No. We need to devise a standard build routine and incorporate it into UX2BS then anyone should be able to build it using:- build foo without even needing to read many pages of docs. > Does this sound reasonable to you? I'll reply to the rest of the email when I have more time to think about the points you have raised. > > Bye, > Andreas > > > P.S.: I apologize to you for this far too long email. **= Email 6 ==========================** Date: Sat, 29 Nov 2003 22:47:04 +0100 From: Andreas Buening Subject: Re: UnixOS/2 distro John Poltorak wrote: > > On Sat, Nov 29, 2003 at 05:53:29PM +0100, Andreas Buening wrote: [snip] > If you have an opportunity to do so could you try running this:- ? > > wget ftp://unixos2: at 213.152.37.92/pub/unixos2/build_system/lib/ux2_bootstrap.cmd > > followed by the retrieved ux2_bootstrap.cmd > > It is best installed on a free partition if possible, althoug if you don't > have a fast link it may be difficult to do. I'll try it. However, I can download that large files only on some Unix systems so the cmd file doesn't really help. ;-) > > If people ask "I want to compile foo but it doesn't work > > because of xyz, what can I do?" then the anwer is "it depends". > > No. We need to devise a standard build routine and incorporate it into > UX2BS then anyone should be able to build it using:- > > build foo > > without even needing to read many pages of docs. The docs are necessary regardless of the build script. It's just that we publically document how to build a specific package. In most cases end users want to run neither a build script nor ./configure. They just want to install software that works. Bye, Andreas **= Email 7 ==========================** Date: Sat, 29 Nov 2003 22:47:42 +0100 From: Andreas Buening Subject: Re: UnixOS/2 distro (documentation) Jeff Robinson wrote: [snip] > I don't know if it is some sort've synchronicity or what, but I've been > actually working on getting the UnixOS2 pages back into shape and up to > date. As of yesterday I've got a new "framework" for the site in > place... the biggest change being that the list of packages now link to > an individual page for each package where we can then put as much > information as we wish. Each package page will also contain links to > pages/topics relevant to that piece of software. Right now I'm just > trying to get my PPWizard scripts into shape so that it'll automatically > generate pages for each package... I'm hoping to have a lot of that > cleaned up by the end of today. Sounds great. > (It's amazing what a Canadian winter > does for indoor productivity!) Ah, so you've already got winter in Canada? :-) Bye, Andreas **= Email 8 ==========================** Date: Sat, 29 Nov 2003 22:52:12 +0100 From: Andreas Buening Subject: Re: UnixOS/2 distro IanM wrote: [snip] > Happy to maintain it, also happy for Ted to maintain it and I'll simply > mirror it, it sort of depends, Ted is probably like me, if the original is > on os2ports the Ted, if the original is on unixos2.com then me, unixos2.com > is ment to be the home of it though, or at least the final resting place. Unfortunately, I don't know what's the difference between unixos2.com and os2ports? Does any of the servers have more total storage, larger bandwidth? Otherwise it doesn't matter which one is the main server as long as Ted and you agree. [snip] Bye, Andreas **= Email 9 ==========================** Date: Sat, 29 Nov 2003 23:27:15 +0000 From: John Poltorak Subject: Re: UnixOS/2 distro On Sat, Nov 29, 2003 at 10:47:04PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > On Sat, Nov 29, 2003 at 05:53:29PM +0100, Andreas Buening wrote: > > [snip] > > > If you have an opportunity to do so could you try running this:- ? > > > > wget ftp://unixos2: at 213.152.37.92/pub/unixos2/build_system/lib/ux2_bootstrap.cmd > > > > followed by the retrieved ux2_bootstrap.cmd > > > > It is best installed on a free partition if possible, althoug if you don't > > have a fast link it may be difficult to do. > > I'll try it. However, I can download that large files only on > some Unix systems so the cmd file doesn't really help. ;-) I guess you have misunderstood what the cmd file does. If you can only grab large files via a Unix system, can you use a proxy server on that system? > > > > If people ask "I want to compile foo but it doesn't work > > > because of xyz, what can I do?" then the anwer is "it depends". > > > > No. We need to devise a standard build routine and incorporate it into > > UX2BS then anyone should be able to build it using:- > > > > build foo > > > > without even needing to read many pages of docs. > > The docs are necessary regardless of the build script. It's > just that we publically document how to build a specific package. > In most cases end users want to run neither a build script nor > ./configure. They just want to install software that works. Yes, of course, but there needs to be some sort of build framework which can produce packages that are known to comply with certain standards and produce programs which are known to co-exist with other programs without requiring 10 different versions of a *INTL*.DLL or whatever. That only be achieved through a standard build framework. > > Bye, > Andreas -- John