Date: Thu, 8 Apr 2004 00:07:03 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 301 ************************************************** Wednesday 07 April 2004 Number 301 ************************************************** Subjects for today 1 Rsync on OS/2 : Anton Monroe 2 Re: Any success? : Anton Monroe 3 Re: Any success? : John Poltorak 4 Re: Rsync on OS/2 : John Poltorak **= Email 1 ==========================** Date: Wed, 7 Apr 2004 07:44:32 -0500 From: Anton Monroe Subject: Rsync on OS/2 One of the things I ran into was the problem that rsync on OS/2 cannot overwrite an existing file. I skimmed through the list archives and found it had been discussed. Of course the real solution is to fix rsync. I didn't see any discussion of what is wrong, but I imagine someone has looked at it by now. At one time I tried to figure out the source, and I think I decided that it was probably in a "robust rename" function that isn't robust enough. As I recall, rsync tries to rename its temporary file to the name of an existing file. If it fails, which it does for some reason under OS/2, rsync assumes it is because of a permission problem and throws out a misleading "permission denied" error. Since I couldn't get rsync to compile, I couldn't experiment. However, the only programming language I am competent in is DOS Basic, so the above may be nonsense. But there is a better workaround than completely deleting the download directory before running rsync each time. You can use rsync's "--backup-dir=" option. With that option, what seems to happen is that rsync moves/renames the original file into the backup directory and then renames its temporary file to the original name. That way you get the major advantage of rsync-- it can analyze the original file and only download the changes, and it doesn't have to re-download files that haven't changed. And it's safer, because a file doesn't get deleted until rsync has successfully downloaded its replacement. But until that bug gets fixed, you still need to remove the backup directory each time. So the ports_update.cmd might look something like this. I've added a few other tweaks also. And yes, I usually do comment this verbosely. rem =============== ports_update.cmd ================================== at echo off call %uxrt%\sbin\ux2_env %uxrt% setlocal rem About the rsync parameters: rem "--exclude=workdir/" tells rsync to ignore any directory called rem "workdir". See the rsync docs for a long explanation of rem how it reads exclusion patterns. rem "--delete" will delete files that do not exist on the server. rem Deletion does not apply to files in or under the excluded rem directory. rem "--backup-dir=" tells rsync where to keep backups. It requires "-b". rem "--window-modify=1" Some filesystems, including HPFS, only keep file rem dates to the nearest even second. If the server uses a rem filesystem that keeps the exact times, rsync will re-sync the rem file every time because the times are always different. rem "--window-modify=1" tells rsync that the dates can differ by rem up to 1 second and still be considered identical. rem "--progress" displays a "x% done" status on the screen so the user rem can have some idea how long it will take. Don't use this rem option if you are going to redirect output to a log file; rem it will just add a lot of garbage to the file. rem rsync needs to see forward slashes here, otherwise it can't create rem the directory. Oddly enough, it is not bothered by the backslash rem or drive letter in %tmp%. I have no idea why that is. set rsbackup=%tmp%/rsyncbackup/ports set rsexclpar="--exclude=workdir/" echo. echo This will update the %uxrt%/ports/ directory from the master server at echo rsync://%host% echo. echo Your existing workdir directories, for instance /ports/fubar/workdir/, echo will be kept. echo. echo Rsync will copy the originals of any changed or deleted files to: echo %rsbackup% echo. echo To cancel, hit Ctrl-C now. echo. pause rem The backup directory has to be removed because there is currently a rem bug in OS/2's rsync that stops it from renaming to an existing file. rm -rf %rsbackup% cd \ports %uxrt%\usr\bin\rsync -abv --progress --delete --modify-window=1 --backup-dir=%rsbackup% %rsexclpar% %host%::build/ports/ %uxrt%/ports/ if errorlevel 1 goto RsyncFailure echo. echo -- Ports Updated Successfully -- echo. goto Done :RsyncFailure echo. echo rsync reported an error, so the Ports update may not be complete echo. goto Done :Done endlocal _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Wed, 7 Apr 2004 07:11:31 -0500 From: Anton Monroe Subject: Re: Any success? On Sat, Mar 13, 2004 at 07:30:15PM +0000, John Poltorak wrote: > Has anyone tried UX2BS recently? I'm new to this list, and I'm not very clear on the difference between UX2BS and UnixOS2. If some of this should go to the other list, let me know. I tried a clean install of UX2BS and it seemed like everything went wrong. I finally figured out that REXX didn't like one line in installpkg.cmd that calls UX2Mknod. As near as I can tell, UX2Mknod isn't actually used, but REXX scans the script first for syntax errors. Every time installpkg.cmd was called, it aborted without installing anything. You can imagine what a cascade of errors that caused later in the UX2BS installation. If that happened to everyone, you would know about it. All I can figure is that it may be because I'm doing this on Warp 3 fixpack 40. Maybe later versions of REXX behave differently? At any rate, the fix is simple. Change line 298 of installpkg.cmd from: if simul="no" then call UX2Mknod(unixroot"\"devname,type,major,minor) to if simul="no" then call UX2Mknod unixroot"\"devname,type,major,minor I got the GCC 3.2.1 and 3.2.2 shells, but the paths still point to /emx/bin. That is, "echo $CC --version" returns "2.8.1". Maybe I don't understand how those shells are supposed to work, or I mangled something. Personally, I like to see what is going on, and some of the scripts keep the screen a little too clean. For instance, build.sh calls wget with "wget -nv". That means I see a message from wget that it is connecting with an ftp server, but I can't tell if wget is busy downloading or if it is waiting on a server that isn't responding. (the server at ftp.gnu.org, in particular, sometimes doesn't respond) And there is no indication how long the download will take. So I changed one line in build.sh from: wcmd="wget -nv --no-clobber --tries=1 -P $REPOSITORY $URL"; to wcmd="wget -vv --no-clobber --tries=1 -P $REPOSITORY $URL"; When trying to repeat a failed install, it adds another copy of /emx/bin, /bin, etc. to the path. It would be nice to avoid that, but it isn't a major problem. Of course, I ran into the rsync problem. I'll write a separate message for that. I really appreciate the work you people are putting into this. I'm the sort of user that can really benefit from it-- knowledgeable enough to want to use ported software but not knowledgeable enough to be able to fix configuration and compiling problems. Anton _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Wed, 7 Apr 2004 14:35:07 +0100 From: John Poltorak Subject: Re: Any success? On Wed, Apr 07, 2004 at 07:11:31AM -0500, Anton Monroe wrote: > On Sat, Mar 13, 2004 at 07:30:15PM +0000, John Poltorak wrote: > > Has anyone tried UX2BS recently? > > I'm new to this list, and I'm not very clear on the difference between > UX2BS and UnixOS2. If some of this should go to the other list, let > me know. UnixOS2 is for general discussion about getting Unix apps to work on OS/2 and providing a Unix-like environment. UX2BS is related to getting the UX2BS framework building Unix apps on OS/2 automatically. There is a degree of overlap, but essentially this list is for feedback about how well (or badly) UX2BS is working. > When trying to repeat a failed install, it adds another copy of > /emx/bin, /bin, etc. to the path. It would be nice to avoid that, but > it isn't a major problem. Of course, I ran into the rsync problem. > I'll write a separate message for that. It sounds to me as though you are using an old version of UX2BS... You need to run this to grab the bootstrap:- wget ftp://unixos2: at 213.152.37.92/pub/unixos2/build_system/lib/ux2_bootstrap.cmd and then run it. > I really appreciate the work you people are putting into this. I'm > the sort of user that can really benefit from it-- knowledgeable > enough to want to use ported software but not knowledgeable enough to > be able to fix configuration and compiling problems. Well the aim is to find people who have managed to work out how to build specific apps and then automate that process so that anyone else can just come along and run 'build appX' and all the messy stuff is taken care of for you. That's the theory anyway... > Anton -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 4 ==========================** Date: Wed, 7 Apr 2004 14:47:41 +0100 From: John Poltorak Subject: Re: Rsync on OS/2 On Wed, Apr 07, 2004 at 07:44:32AM -0500, Anton Monroe wrote: > Since I couldn't get rsync to compile, I > couldn't experiment. However, the only programming language I am > competent in is DOS Basic, so the above may be nonsense. I thought RSYNC was one of the apps that was buildable using UX2BS... I'll check. -- John _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs