From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 11 Jan 2003 04:48:11 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 10 ************************************************** Friday 10 January 2003 Number 10 ************************************************** Subjects for today 1 Re: Mounting an CDROM ISO image as a filesystem : email at eracc.hypermart.net (ERACC Lists) 2 Re: OS/2 in the News at /. .. again! : Adrian Gschwend" 3 Re: UnixOS2 "enhancements" : Adrian Gschwend" 4 Re: UnixOS2 "enhancements" : Thomas Dickey 5 Re: UnixOS2 "enhancements" : Jeff Robinson 6 Bugtracking (was: UnixOS2 "enhancements") : Jeff Robinson 7 Re: UnixOS2 "enhancements" : John Poltorak 8 Re: UnixOS2 "enhancements" : Adrian Gschwend" 9 Re: UnixOS2 "enhancements" : John Poltorak 10 Re: UnixOS2 "enhancements" : Adrian Gschwend" 11 Re: UnixOS2 "enhancements" : John Poltorak 12 Re: UnixOS2 "enhancements" : Stefan Neis 13 Re: UnixOS2 "enhancements" : John Poltorak 14 Re: UnixOS2 "enhancements" : John Poltorak 15 Re: UnixOS2 "enhancements" : DWParsons at t-online.de (Dave Parsons) 16 Re: UnixOS2 "enhancements" : Andreas Buening 17 Make v3.80 : John Poltorak 18 Re: Ncurses problem? : Thomas Dickey 19 Re: Bugtracking (was: UnixOS2 "enhancements") : John Poltorak 20 Re: UnixOS2 "enhancements" : Steve Wendt" 21 Re: UnixOS2 "enhancements" : Steve Wendt" **= Email 1 ==========================** Date: Sat, 11 Jan 2003 00:13:21 -0600 From: email at eracc.hypermart.net (ERACC Lists) Subject: Re: Mounting an CDROM ISO image as a filesystem In: <20030110205223.V83 at manninghammills.org> On: Fri, 10 Jan 2003 20:52:23 +0000 Screaming: Re: Mounting an CDROM ISO image as a filesystem John Poltorak did rant: +On Fri, Jan 10, 2003 at 11:45:08AM -0600, ERACC Lists wrote: > In: +<20030109131214.N83 at manninghammills.org> +> On: Thu, 9 Jan 2003 13:12:14 +0000 +> Screaming: Mounting an CDROM ISO image as a filesystem +> John Poltorak did rant: +> +> +How do I mount a CDROM ISO image so that I can see it as a file system +> +under a drive letter? +> +> If you just want read access try using the "F" file manager. I use it +> on OS/2 to examine ISOs and extract or read files in same. It does +> *not* need the ISO to become a loaded file system to open and examine +> or extract from it. Granted it does have problems directly copying +> files that are in ISO subdirectories but they will get copied to your +> %TEMP%\$f_tmp\ directory if you try to view them so they can still be +> retrieved. Perhaps a newer version of "F" will work better than the +> one I have. According to the help page I am running version 4.64 of +> "F". +Many thanks for this tip. It seems amazing to be able to access the an +ISO image so easily. +I've just download v4.70 and am struggling to find my way around. +I've been using File Commander for so long that I'm struggling to make F +do anything at all, but I do see a list of files within the ISO image +files I have. Now I need to find out what I can actually do. F1 is your buddy. Use F1 and look at the list of keys and info under Quick Start. What is really cool about F is it is available on OS/2, Linux, AIX, *BSD and Win32. So once you learn it you can use it on all those platforms. :-) Note that the directory from which you start F will contain all the files F needs. If they don't exist they will be created. So, you will probably want to put it in some place where you call it with a .CMD like I do. Gene -- +=========================-=>Unix & OS/2<=-=========================+ # Owner and C.E.O. - ERA Computer Consulting - Jackson, TN USA # # eCS,OS/2,UnixWare,OpenServer & Linux Business Computing Solutions # # Please visit our www pages at http://eracc.hypermart.net/ # +===================================================================+ We run IBM OS/2 v.4.00, Revision 9.036 Sysinfo: 41 Processes, 177 Threads, uptime is 0d 16h 12m 46s 29ms **= Email 2 ==========================** Date: Sat, 11 Jan 2003 01:29:38 +0100 (CET) From: "Adrian Gschwend" Subject: Re: OS/2 in the News at /. .. again! On Fri, 10 Jan 2003 14:51:22 -0800 (PST), Steve Wendt wrote: >> For me I have to say that I gave up /. month ago already. The signal to >> noise ratio is way too low nowadays. > >osnews has been a good place to go for about a year now. Yep that's true, they are much more friendly for other things than linux out there. I just always forget to check the page because I'm not yet used to it. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 3 ==========================** Date: Sat, 11 Jan 2003 01:32:44 +0100 (CET) From: "Adrian Gschwend" Subject: Re: UnixOS2 "enhancements" On Fri, 10 Jan 2003 17:41:09 -0600, Jeff Robinson wrote: Hi Jeff, >Should we have some sort've bug-tracking mechanism like bugzilla >(http://www.bugzilla.org/) or XTracker (http://xtracker.netlabs.org/) to >keep track of what people are working on and issues that need to be tackled? Sounds good for me, simplest thing would be to create a new project at netlabs.org for that. I can do that immediately if we want. >Would a naming convention such as: >bash-2.03-ux2.zip >instead of just plain: >bash.zip I would definitely vote for that. makes it much easier to keep the system up to date. Also most linux systems are doing that as well I guess. >A naming system like this would be relatively easy to maintain as well >as providing a reasonable amount of information about the archive's >contents at a glance. Both of these naming methods will also help sort >the packages by name and then by version automatically (if the server is >setup in that fashion). ACK cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 4 ==========================** Date: Sat, 11 Jan 2003 07:49:44 -0500 From: Thomas Dickey Subject: Re: UnixOS2 "enhancements" On Sat, Jan 11, 2003 at 12:03:14PM +0100, Adrian Gschwend wrote: > > Well if I download a package I have no clue which version it is like > this. That's the reason why I prefer it this way. Also if there is a > compatibility problem I can always go back the previous version and > like this I most probably override it. During my diploma work I > realized that it's very handy to be able to install an older version. > We had problems with the latest autoconf version on our Debian Linux > system so we simply installed the version that worked and everything > was fine again. Later the Debian bash package had an error, it took > quite long until we discovered that and switched back to the old > version. That wouldn't have been possible without version names in the > archive. even cygwin provides this capability. The dll that they released in mid-September was basically unusable since it trashed the display in console windows. So I went back. It's also important to have a good changelog (with dates). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 5 ==========================** Date: Sat, 11 Jan 2003 08:10:49 -0600 From: Jeff Robinson Subject: Re: UnixOS2 "enhancements" John Poltorak wrote: > On Fri, Jan 10, 2003 at 05:41:09PM -0600, Jeff Robinson wrote: >>Would a naming convention such as: >>bash-2.03-ux2.zip >>instead of just plain: >>bash.zip >> >>...or if a tool doesn't necessarily have a version number, using the >>yy-mm-dd of the build instead. >>(eg: fooutil-03-01-10-ux2.zip) >> >>A naming system like this would be relatively easy to maintain as well >>as providing a reasonable amount of information about the archive's >>contents at a glance. Both of these naming methods will also help sort >>the packages by name and then by version automatically (if the server is >>setup in that fashion). > > > Personally, I don't see any reaon for it. > > The most recent version of SED should always be called SED and there > should only be one version of SED available at any given release of > UnixOS/2. An index of available files should provide summary information > such as version. > > Messing around naming conventions is peripheral to actually getting apps > built and providing a comprehensive, cohesive distro which, IMV, should be > our primary concern. > I can understand the point that in any release of UnixOS2 that it should only have one version of each file (though we already have bash.zip and bash1.zip with the two different versions). Part of the reason I brought this up previously is that when I grab these archives I don't know "what" they are, and right now the version can make a difference with the some of existing tools that are out there. Going by example, (some of the) Linux vendors seem to be using this convention as well, such as Slackware (ftp://ftp.slackware.com/pub/slackware/slackware-current/slackware/ap) as well as a similar naming convention for a lot of library packages. My feeling is that is this distribution has been around this long they have probably run into a number of problems much like we are facing and are doing many of these things for a specific reason. According to hints I've found on the 'net (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=slrnau538p.23h.Chiron_Files%40raven.home&rnum=1), the reason previous versions of Slackware used short names was to be 8.3 compliant; but in new versions that have completely abandoned that practice. My feeling is it would be better to adopt this at the beginning than try to implement it later on. The Slackware folks had issues about upgradepkg not working nicely when the name-change was done as doing "upgradepkg foo-5.1" would not delete "foo", but install "foo-5.1" beside it. Just a potential bit of junk that people would have to work around. The makepkg man-page (http://archlinux.org/makepkg.man.html) details the specific (Slackware) naming convention. Currently I see (and feel free to add your own points): /Pros:/ - Easy to tell the version at a glance - Simple to differentiate between standard zips and ux2 pkgs - Easy to maintain a useful "description" of the package /Cons:/ - file names are a bit more unwieldy from the command line My gut feeling is the long naming convention exists for a practical reason, so it is something that I'd certainly like to look into. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 6 ==========================** Date: Sat, 11 Jan 2003 09:33:44 -0600 From: Jeff Robinson Subject: Bugtracking (was: UnixOS2 "enhancements") Adrian Gschwend wrote: > On Fri, 10 Jan 2003 19:40:28 -0600, Jeff Robinson wrote: > > >>XTracker looks quite interesting... and much more accessible than >>Bugzilla. Just off the top of my head I'm also wondering how UnixOS2 > > > It is, Bugzilla is a PITA IMHO. xtracker is pretty straight forward to > understand. > > Unfortunately I've not had much experience with either Bugzilla or xTracker aside from filing a couple bugs on each one... I don't think I'd be able to make a well-informed choice between the two at this point. I'm also not certain what other bugtracking systems are out there that we could use. John had mentioned trying to get the project on Sourceforge.net which also has their own bugtracking facilities. I guess a couple questions that need to be looked at then would be: - What services are available to us if we want to run our own bug-tracking software? - Would private control (run by a member of UnixOS2) or 3rd party control (such as Sourceforge) be better? - What would work best for a multi-part project such as UnixOS2? Part of the reason I bring up the issue of bugtracking is that some of the folks doing the Mozilla-port right now have some issues with some of the ported tools but don't know where to report any problems, especially as the authors of some tools are no longer available. I believe some of the Mozilla-porters monitor the UnixOS2 list, but don't subscribe to it. My initial leaning would be towards xTracker for the reason that it is run by an OS/2 user for OS/2 projects, so obviously Adrian knows what we're all about... plus the fact that he's made the resources immediately available. Indeed, Bugzilla does seem to be more "comprehensive"... or daunting might even be the word, but we'll need to find a server that can run it, as well. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 7 ==========================** Date: Sat, 11 Jan 2003 10:24:13 +0000 From: John Poltorak Subject: Re: UnixOS2 "enhancements" On Fri, Jan 10, 2003 at 05:41:09PM -0600, Jeff Robinson wrote: > In working on getting a UnixOS2 build environment together to work on > building Mozilla with gcc, a couple things have come to my attention. > > Should we have some sort've bug-tracking mechanism like bugzilla > (http://www.bugzilla.org/) or XTracker (http://xtracker.netlabs.org/) to > keep track of what people are working on and issues that need to be tackled? My preferred option has always been to get UnixOS/2 set up as a SourceForge project, which would automatically provide it with numerous built in facilities, but no one else seems interested in the idea.. > A second item I've been looking at is the naming convention for the > UnixOS2 packages that are being created. This may become less of an > issue in the future as things tend to stabalise, but right now what some > of these packages are > (http://unix.os2site.com/sw/pub/unixos2/packages/index.html); at least > version-wise. I know this could be fixed by having a description for > each file, but descriptions tend to require a bit more maintenance and > so are less likely to be updated than the actual name of the archive. > It would also be nice to know that the archive is a UnixOS2 package over > and above just knowing it is a plain .zip; this would be more of an > issue when archives become more widely distributed. > > Would a naming convention such as: > bash-2.03-ux2.zip > instead of just plain: > bash.zip > > ...or if a tool doesn't necessarily have a version number, using the > yy-mm-dd of the build instead. > (eg: fooutil-03-01-10-ux2.zip) > > A naming system like this would be relatively easy to maintain as well > as providing a reasonable amount of information about the archive's > contents at a glance. Both of these naming methods will also help sort > the packages by name and then by version automatically (if the server is > setup in that fashion). Personally, I don't see any reaon for it. The most recent version of SED should always be called SED and there should only be one version of SED available at any given release of UnixOS/2. An index of available files should provide summary information such as version. Messing around naming conventions is peripheral to actually getting apps built and providing a comprehensive, cohesive distro which, IMV, should be our primary concern. > Jeff > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- > > -- John **= Email 8 ==========================** Date: Sat, 11 Jan 2003 11:37:40 +0100 (CET) From: "Adrian Gschwend" Subject: Re: UnixOS2 "enhancements" On Fri, 10 Jan 2003 19:40:28 -0600, Jeff Robinson wrote: >XTracker looks quite interesting... and much more accessible than >Bugzilla. Just off the top of my head I'm also wondering how UnixOS2 It is, Bugzilla is a PITA IMHO. xtracker is pretty straight forward to understand. >would be handled... obviously there would be one entry for the project >as a whole, but XTracker also has the capability of tracking >"subprojects"? Say we want to be able to have a section devoted to the >packaging tool, another to gmake, etc? I think I recall something like >that when I filed an XWorkplace bug, but other than that I don't know a >lot about XTracker... Yes you can add "categories" to the project so we could create different categories as it makes sense. For sure I can also create more than one project but I prefer to keep it on a minimum. >If there aren't any other suggestions for a naming convention (or >reasons why we should stay with the existing naming convention), I can >add these "guidelines" to the UnixOS2 webpages. ok for me. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 9 ==========================** Date: Sat, 11 Jan 2003 11:54:45 +0000 From: John Poltorak Subject: Re: UnixOS2 "enhancements" On Sat, Jan 11, 2003 at 12:03:14PM +0100, Adrian Gschwend wrote: > >Personally, I don't see any reaon for it. > > > >The most recent version of SED should always be called SED and there > >should only be one version of SED available at any given release of > >UnixOS/2. An index of available files should provide summary information > >such as version. > > > >Messing around naming conventions is peripheral to actually getting apps > >built and providing a comprehensive, cohesive distro which, IMV, should be > >our primary concern. > > Well if I download a package I have no clue which version it is like > this. That is not the case. As I said, an index will give you version information, and will also be included within the package itself. I don't see any justification in including version information in the filename. There are far too many other things to do at the moment, and this is purely cosmetic, IMV. > That's the reason why I prefer it this way. Also if there is a > compatibility problem I can always go back the previous version and > like this I most probably override it. During my diploma work I > realized that it's very handy to be able to install an older version. > We had problems with the latest autoconf version on our Debian Linux > system so we simply installed the version that worked and everything > was fine again. Later the Debian bash package had an error, it took > quite long until we discovered that and switched back to the old > version. That wouldn't have been possible without version names in the > archive. But we are not talking about Debian. We are taliking about UnixOS/2. A version of an app will not be included if it does not work with the rest of the distro. The OS/2 Build System should provide you with a means of building a back level version of an app should you wish to have one. If the situation was as you described under Debian, then there is a problem with Debian, if apps included with it do not work with each other. > cu > > Adrian > > > -- > Adrian Gschwend > at netlabs.org > > ktk [a t] netlabs.org > ------- > Free Software for OS/2 and eCS > http://www.netlabs.org > -- John **= Email 10 ==========================** Date: Sat, 11 Jan 2003 12:03:14 +0100 (CET) From: "Adrian Gschwend" Subject: Re: UnixOS2 "enhancements" On Sat, 11 Jan 2003 10:24:13 +0000, John Poltorak wrote: >My preferred option has always been to get UnixOS/2 set up as a >SourceForge project, which would automatically provide it with numerous >built in facilities, but no one else seems interested in the idea.. Well I won't vote for sourceforge for obvious reasons :-) I don't like the fact that project admins have to care about the design of the page at sourceforge. IMHO they should just concentrate on the content and the rest should be done by other people. That's what I try to do with netlabs. For sure sourceforge provides quite a lot of stuff but I'm catching up at netlabs right now. And I don't know if you ever tried to register a bug in Bugzilla, it's way more difficult than in xtracker. >Personally, I don't see any reaon for it. > >The most recent version of SED should always be called SED and there >should only be one version of SED available at any given release of >UnixOS/2. An index of available files should provide summary information >such as version. > >Messing around naming conventions is peripheral to actually getting apps >built and providing a comprehensive, cohesive distro which, IMV, should be >our primary concern. Well if I download a package I have no clue which version it is like this. That's the reason why I prefer it this way. Also if there is a compatibility problem I can always go back the previous version and like this I most probably override it. During my diploma work I realized that it's very handy to be able to install an older version. We had problems with the latest autoconf version on our Debian Linux system so we simply installed the version that worked and everything was fine again. Later the Debian bash package had an error, it took quite long until we discovered that and switched back to the old version. That wouldn't have been possible without version names in the archive. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 11 ==========================** Date: Sat, 11 Jan 2003 12:26:05 +0000 From: John Poltorak Subject: Re: UnixOS2 "enhancements" On Sat, Jan 11, 2003 at 01:03:13PM +0100, Stefan Neis wrote: > On Sat, 11 Jan 2003, Adrian Gschwend wrote: > > > On Sat, 11 Jan 2003 10:24:13 +0000, John Poltorak wrote: > > > > >My preferred option has always been to get UnixOS/2 set up as a > > >SourceForge project, which would automatically provide it with numerous > > >built in facilities, but no one else seems interested in the idea.. > > AFAIR, you tried to get something set up and SourceForge people showed > no interest in that? I've never set up a SourceForge project before, so I guess I didn't go through the procedures properly. > So what's the point in voicing any interest or > dislike for thise idea on this mailing list? :-( Maybe someone with an understanding of how SourceForge works could help me set it up... > > >Messing around naming conventions is peripheral to actually getting apps > > >built and providing a comprehensive, cohesive distro which, IMV, should be > > >our primary concern. > > > > Well if I download a package I have no clue which version it is like > > this. > > Especially, you don't even see: Is it the version I did already download > or is it something new. Once we are just distributing complete > distributions, that shouldn't matter any more, though... Currently unixos2.com is mainly a dumping ground for the most recent OS/2 versions of many apps. The available packages have simply been assembled in an adhoc manner as a single point of call to establish a point of presence. The next stage is to build a cohesive distro from source. I'm hoping to be able to use my OS/2 Build System to do this. That's the hard bit, and deciding on a naming convention packages will do nothing to speed up the process. My current priority is to put together a working distro, then worry about how to create small discrete packages afterwards. The packaging and naming conventions could even be built into the Build System, but creating working apps is the major concern. > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 12 ==========================** Date: Sat, 11 Jan 2003 13:03:13 +0100 (CET) From: Stefan Neis Subject: Re: UnixOS2 "enhancements" On Sat, 11 Jan 2003, Adrian Gschwend wrote: > On Sat, 11 Jan 2003 10:24:13 +0000, John Poltorak wrote: > > >My preferred option has always been to get UnixOS/2 set up as a > >SourceForge project, which would automatically provide it with numerous > >built in facilities, but no one else seems interested in the idea.. AFAIR, you tried to get something set up and SourceForge people showed no interest in that? So what's the point in voicing any interest or dislike for thise idea on this mailing list? :-( > Well I won't vote for sourceforge for obvious reasons :-) ;-) Well, is it so obvious? More projects implies more work for you and need for more resources, so I could understand if you sometimes would say "Oh, please, if you can get somewhere else, do that...". > And I don't know if you ever tried to > register a bug in Bugzilla, it's way more difficult than in xtracker. Actually, I've been using Bugzilla from both sides (filing bugs for others and handling "my own" bugs), whereas I know nothing about xtracker yet. I don't know how common this is among people interested in UnixOS/2, but Bugzilla seems rather widely used by now ... > >Messing around naming conventions is peripheral to actually getting apps > >built and providing a comprehensive, cohesive distro which, IMV, should be > >our primary concern. > > Well if I download a package I have no clue which version it is like > this. Especially, you don't even see: Is it the version I did already download or is it something new. Once we are just distributing complete distributions, that shouldn't matter any more, though... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 13 ==========================** Date: Sat, 11 Jan 2003 14:33:10 +0000 From: John Poltorak Subject: Re: UnixOS2 "enhancements" On Sat, Jan 11, 2003 at 08:10:49AM -0600, Jeff Robinson wrote: > >>A naming system like this would be relatively easy to maintain as well > >>as providing a reasonable amount of information about the archive's > >>contents at a glance. Both of these naming methods will also help sort > >>the packages by name and then by version automatically (if the server is > >>setup in that fashion). > > > > > > Personally, I don't see any reaon for it. > > > > The most recent version of SED should always be called SED and there > > should only be one version of SED available at any given release of > > UnixOS/2. An index of available files should provide summary information > > such as version. > > > > Messing around naming conventions is peripheral to actually getting apps > > built and providing a comprehensive, cohesive distro which, IMV, should be > > our primary concern. > > > > I can understand the point that in any release of UnixOS2 that it should > only have one version of each file (though we already have bash.zip and > bash1.zip with the two different versions). This is only because I was trying to follow Slackware, but Bash1 has now disappeared from Slackware v8. > Part of the reason I > brought this up previously is that when I grab these archives I don't > know "what" they are, and right now the version can make a difference > with the some of existing tools that are out there. As I mentioned before, the current packages were assembled to provide a point of presence, and were a short term objective. The next phase of putting together UnixOS/2 will create a new set of packages from source. They will form the base of a new release of packages. > My feeling is that is this distribution has been around this long they > have probably run into a number of problems much like we are facing and > are doing many of these things for a specific reason. According to > hints I've found on the 'net > (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=slrnau538p.23h.Chiron_Files%40raven.home&rnum=1), > the reason previous versions of Slackware used short names was to be 8.3 > compliant; but in new versions that have completely abandoned that > practice. My feeling is it would be better to adopt this at the > beginning than try to implement it later on. The Slackware folks had > issues about upgradepkg not working nicely when the name-change was done > as doing "upgradepkg foo-5.1" would not delete "foo", but install > "foo-5.1" beside it. Just a potential bit of junk that people would > have to work around. The makepkg man-page > (http://archlinux.org/makepkg.man.html) details the specific (Slackware) > naming convention. > > Currently I see (and feel free to add your own points): > /Pros:/ > - Easy to tell the version at a glance > - Simple to differentiate between standard zips and ux2 pkgs > - Easy to maintain a useful "description" of the package I don't see any reason to keep more than on version of any package. The 'description' of a package will be the same irrespective of its version number. > /Cons:/ > - file names are a bit more unwieldy from the command line > > My gut feeling is the long naming convention exists for a practical > reason, so it is something that I'd certainly like to look into. If it's something you need, then feel free to devise a way of incorporating it. > Jeff > > > > > > > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- > > -- John **= Email 14 ==========================** Date: Sat, 11 Jan 2003 15:42:46 +0000 From: John Poltorak Subject: Re: UnixOS2 "enhancements" On Sat, Jan 11, 2003 at 03:46:56PM +0100, Dave Parsons wrote: > As one who has wasted many hours downloading things I didn't > want, because I couldn't tell which version it was until I > had downloaded it, IMHO the filename should contain the > version number as a minimum and preferably the date as well. I, too, have wasted many hours downloading things I didn't want, which one of the reasons I thought something like UnixOS/2 would be a good thing. The idea is to have a single distro where all the apps included are known to co-exist. Hobbes and Leo are simply repositories of files and no effort is made to tidy these sites up. unixos2.com is not there to replicate Hobbes or Leo, it should be seen more in terms of slackware.com. > As, I think others have implied, the latest version is not > always the one you need. Well there is no need for UnixOS/2 to include the latest version of an app if it does not work. That fact that a particular version is included should indicate that it is, to some extent, 'approved'. > Dave -- John **= Email 15 ==========================** Date: Sat, 11 Jan 2003 15:46:56 +0100 (CET) From: DWParsons at t-online.de (Dave Parsons) Subject: Re: UnixOS2 "enhancements" On Fri, 10 Jan 2003 19:40:28 -0600, Jeff Robinson wrote: > > > >>Would a naming convention such as: > >>bash-2.03-ux2.zip > >>instead of just plain: > >>bash.zip > > > > > > I would definitely vote for that. makes it much easier to keep the > > system up to date. Also most linux systems are doing that as well I > > guess. > > > > If there aren't any other suggestions for a naming convention (or > reasons why we should stay with the existing naming convention), I can > add these "guidelines" to the UnixOS2 webpages. > > Jeff As one who has wasted many hours downloading things I didn't want, because I couldn't tell which version it was until I had downloaded it, IMHO the filename should contain the version number as a minimum and preferably the date as well. As, I think others have implied, the latest version is not always the one you need. Dave **= Email 16 ==========================** Date: Sat, 11 Jan 2003 17:09:29 +0100 From: Andreas Buening Subject: Re: UnixOS2 "enhancements" John Poltorak wrote: > > On Sat, Jan 11, 2003 at 12:03:14PM +0100, Adrian Gschwend wrote: [snip] > > Well if I download a package I have no clue which version it is like > > this. > > That is not the case. As I said, an index will give you version > information, and will also be included within the package itself. > I don't see any justification in including version information in the > filename. There are far too many other things to do at the moment, and > this is purely cosmetic, IMV. Very often different versions of the same program are floating around and in general you have no highly sophisticated index on a ftp server. "make.zip" doesn't tell you much about what you're going to find in it. A reasonable (and unique!) naming scheme can help a lot. And it's not really an additional effort to run "zip -xyz make-n_m_k.zip *" instead of "zip -xyz make.zip *" when you create the final archive for your package. > > That's the reason why I prefer it this way. Also if there is a > > compatibility problem I can always go back the previous version and > > like this I most probably override it. During my diploma work I > > realized that it's very handy to be able to install an older version. > > We had problems with the latest autoconf version on our Debian Linux > > system so we simply installed the version that worked and everything > > was fine again. Later the Debian bash package had an error, it took > > quite long until we discovered that and switched back to the old > > version. That wouldn't have been possible without version names in the > > archive. > > But we are not talking about Debian. We are taliking about UnixOS/2. > A version of an app will not be included if it does not work with the rest > of the distro. Nobody can guarantee that the included "stable" version of foo works as expected for everybody . A bug can ever occur. And then as Adrian has just pointed out you want to be able to downgrade to an older version _now_ instead of waiting for the bug fix for several months. You may discover that 3.7.6 doesn't work for a specific purpose but you remember that 1.8.3 did. Then you need to get the old binary compilation to check whether it really worked with this version. Maybe it's just a different compiler flag, maybe a different compiler option, maybe a real bug. This is what the http://unix.os2site.com/sw/pub/binary/ tree is for IMHO. It contains builds of the current and _all_ earlier versions of all packages. If you want to downgrade or upgrade only one specific package you download the version you want and install it. I suggest to use the same names for source packages like on Unix ("foo-1_2_3.zip" instead of "foo-1_2_3_tar.gz") and something similiar for binary packages ("foo-1_2_3-bin.zip" or "foo-1_2_3-ux2.zip"). However, for a compilation of packages (aka a UnixOS/2 distro) it's more convenient to choose one name without version if you have one global install script that installs all packages by name. I.e. then you have something like the following: /sw/pub/source/foo/foo-1_2_3.zip (source of 1.2.3) /sw/pub/source/foo/foo-1_2_4.zip (source of 1.2.4, still beta) /sw/pub/binary/foo/foo-1_2_3-bin.zip (binaries of 1.2.3) /sw/pub/binary/foo/foo-1_2_4-bin-beta.zip (binaries of 1.2.4) /sw/pub/distro/unixos2-0_1/packages/foo.zip (latest stable, i.e. 1.2.3) /sw/pub/distro/unixos2-beta/packages/foo.zip (latest beta, i.e. 1.2.4) /sw/pub/distro/unixos2-0_1/ in this example contains the stable UnixOS/2 distro 0.1 while /sw/pub/distro/unixos2-beta/ contains the latest beta. > The OS/2 Build System should provide you with a means of building a back > level version of an app should you wish to have one. For every new version of a package there can be a change in the package options or supported features. Files may have moved or vanished. In most cases it might be sufficient to run "./configure --help" to check for new or changed options. But for this you need human intelligence to find out. You need a package maintainer who compiles the latest version and uploads the new stuff. [snip] Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 17 ==========================** Date: Sat, 11 Jan 2003 19:03:16 +0000 From: John Poltorak Subject: Make v3.80 I managed to build Make v3.80 straight from the GNU source a few weeks ago, but it didn't actually work properly. Are there any known problems with it? -- John **= Email 18 ==========================** Date: Sat, 11 Jan 2003 19:13:34 -0500 From: Thomas Dickey Subject: Re: Ncurses problem? On Tue, Jan 07, 2003 at 10:32:47AM +0000, John Poltorak wrote: > > I'm not sure if this is a problem or not, but I noticed this msg whilst > building NCURSES (5.3) :- > > > sh ./run_tic.sh > ** Building terminfo database, please wait... > ** adjusting tabset paths > Running tic to install c:/usr/share/terminfo ... > > You may see messages regarding unknown capabilities, e.g., AX. > These are extended terminal capabilities which can be compiled > using > tic -x > Read the INSTALL document before doing this - it can cause > problems for older ncurses applications. > > 38 entries written to /usr/share/terminfo > ** built new c:/usr/share/terminfo > cp: ../share/terminfo: No such file or directory I see it now - the script is attempting to make a symbolic link (for compatibility with old applications) from /usr/lib/terminfo to /usr/share/terminfo. I just added a better message to the script (can't do much more than that). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 19 ==========================** Date: Sat, 11 Jan 2003 19:14:04 +0000 From: John Poltorak Subject: Re: Bugtracking (was: UnixOS2 "enhancements") On Sat, Jan 11, 2003 at 09:33:44AM -0600, Jeff Robinson wrote: > Part of the reason I bring up the issue of bugtracking is that some of > the folks doing the Mozilla-port right now have some issues with some of > the ported tools but don't know where to report any problems, especially > as the authors of some tools are no longer available. When KUR departed from the OS/2 scene most of his ports were left abandoned, although Jun Sawataishi and Andreas Buening seem to have taken over a number of them subsequently. I suppose it's up to each individual porter to decide if/how to track bugs. I'm not sure what we do about those ports which no one has taken over... > Jeff > > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- -- John **= Email 20 ==========================** Date: Sat, 11 Jan 2003 20:49:49 -0800 (PST) From: "Steve Wendt" Subject: Re: UnixOS2 "enhancements" On Sat, 11 Jan 2003 13:03:13 +0100 (CET), Stefan Neis wrote: >Actually, I've been using Bugzilla from both sides (filing bugs for others >and handling "my own" bugs), whereas I know nothing about xtracker yet. >I don't know how common this is among people interested in UnixOS/2, but >Bugzilla seems rather widely used by now ... Same here. xTracker is usable, but I can't say I *prefer* it to Bugzilla. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 21 ==========================** Date: Sat, 11 Jan 2003 20:52:23 -0800 (PST) From: "Steve Wendt" Subject: Re: UnixOS2 "enhancements" On Sat, 11 Jan 2003 11:54:45 +0000, John Poltorak wrote: >> >Messing around naming conventions is peripheral to actually getting apps >> >built and providing a comprehensive, cohesive distro which, IMV, should be >> >our primary concern. Yes... >But we are not talking about Debian. We are taliking about UnixOS/2. >A version of an app will not be included if it does not work with the rest >of the distro. That sounds very naive... :) There will always be cases that aren't tested, and suddenly it becomes very difficult figuring out how to get the old one that you know did exactly what you needed for this special case, which has to be done *yesterday*. >If the situation was as you described under Debian, then there is a >problem with Debian, if apps included with it do not work with each other. Not really... it will never be the case that *everything* you ever want to use will come with distribution X (be it Debian or UnixOS2), so there WILL be issues like this - not everything progresses at the same rate. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.)