OS2 World Community Forum
WebSite Information => Article Discussions => Topic started by: Martin Iturbide on March 11, 2025, 03:46:25 am
-
Hello.
I'm going to create some .rpm packages of OS/2 software that I use, and I would like to share it here. If there is any comment on improvements please let me know.
Regards
-
This is for DataSeeker.
Update: Files Removed. Newer version in following posts.
-
Here it is a simple one for FT.CMD.
-
Hi Martin,
Here it is a simple one for FT.CMD.
Good work. Shouldn't a Rexx script be noarch rather then pentium4?
-
If interested, you can build a rpm package for AVxCAT ;)
-
Hi Martin,
Here it is a simple one for FT.CMD.
Good work. Shouldn't a Rexx script be noarch rather then pentium4?
Thanks for the feedback.
I think you are right about this. I will fix it tonight.
Regards
-
Hello Remy
If interested, you can build a rpm package for AVxCAT ;)
I think it can be interesting to try it.
My issue with OS/2 native software (not ported from other sources), is where to put the files in the FHS (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) structure. (I think it was discussed before). This is it because I want to adhere (as possible) to FHS and not just drop all files to /usr/bin
For DataSeeker I did:
%files
%{_bindir}/*.exe -> all .exe to /usr/bin
%{_bindir}/*.cmd -> all .exe to /usr/bin
%{_bindir}/*.dbg -> all .dbg to /usr/bin
%{_bindir}/*.nls -> all .nls to /usr/bin
%doc *.txt -> all .txt to usr/share/<name of package>/doc
%doc COPYING -> COPYING to usr/share/<name of package>/doc
/@unixroot/usr/share/os2/help/*.hlp -> all .hlp to /usr/share/os2/help/
Usually the unix/linux ported software uses a lo the "/usr/share/<name of the package>" for extra stuff, but it does not work by default on regular OS/2 compiled apps.
And I think that I never learn how to make the RPM to install on C:\Programs\ or any other part of the hard drive.
Comments are welcome.
Regards
-
Hello Remy
If interested, you can build a rpm package for AVxCAT ;)
I think it can be interesting to try it.
My issue with OS/2 native software (not ported from other sources), is where to put the files in the FHS (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) structure. (I think it was discussed before)
For DataSeeker I did:
%files
%{_bindir}/*.exe -> all .exe to /usr/bin
%{_bindir}/*.cmd -> all .exe to /usr/bin
%{_bindir}/*.dbg -> all .dbg to /usr/bin
%{_bindir}/*.nls -> all .nls to /usr/bin
%doc *.txt -> all .txt to usr/share/<name of package>/doc
%doc COPYING -> COPYING to usr/share/<name of package>/doc
/@unixroot/usr/share/os2/help/*.hlp -> all .hlp to /usr/share/os2/help/
Usually the unix/linux ported software uses a lo the "/usr/share/<name of the package>" for extra stuff, but it does not work by default on regular OS/2 compiled apps.
And I think that I never learn how to make the RPM to install on C:\Programs\ or any other part of the hard drive.
Comments are welcome.
Regards
I'll update AVxCAT to allow easy RPM packaging using general @unixroot structure
(allowing subpath under AVxCAT install path or use recommended @unixroot paths when rpm installed for easy rpm packaging)
I'll tell it to ytou as soon it is ready as well destination path.
-
Hello Dave
Just another question here.
If I have no idea how to the OS/2 program was compiled, like DataSeeker, is it ok to put it on "pentium4"? I personally think it is no harm, but I don't know if it has deeper implications.
Regards
-
Here it is FT with noarch.
-
Hello Dave
Just another question here.
If I have no idea how to the OS/2 program was compiled, like DataSeeker, is it ok to put it on "pentium4"? I personally think it is no harm, but I don't know if it has deeper implications.
Regards
The only harm is that someone with RPM setup for i686 won't be able to use the RPM. Reasons for using i686 include personal preference but more important, a system that doesn't support SSE[2] due to an old CPU or using an operating system that doesn't support SSE such as Warp 4 or older. I can't remember when our kernel started supporting SSE[2], might have been FP13-15 or a later kernel release.
Also not sure if RPM will work on older versions of OS/2.
The other question is do they need to be P4? IIRC, only GCC supports P4 so other programs could be i686. In theory a P4 system should be able to use i686 RPM's fine.
Edit: Even GCC defaults to i686 or i386 so without passing -march=pentium4 (and hopefully -mtune=generic or i686) most GCC programs can be i686 as well.
-
I don't think DataSeeker needs more than 686. It's compiled with VAC3.65. But I don't remember if I set any special option. OTOH there was no single report of anyone that it does not work on his system. So maybe even 386 is enough.
-
%files
%{_bindir}/*.exe -> all .exe to /usr/bin
%{_bindir}/*.cmd -> all .exe to /usr/bin
%{_bindir}/*.dbg -> all .dbg to /usr/bin
%{_bindir}/*.nls -> all .nls to /usr/bin
%doc *.txt -> all .txt to usr/share/<name of package>/doc
%doc COPYING -> COPYING to usr/share/<name of package>/doc
/@unixroot/usr/share/os2/help/*.hlp -> all .hlp to /usr/share/os2/help/
I think that it would be better into:
%doc *.txt -> all .txt to usr/share/doc/<name of package>
%doc COPYING -> COPYING to usr/share/licenses/<name of package>
-
Hello
So, the suggestion for Data Seeker will be to put on 386, mostly for old hardware that uses RPM. I guess it will not produce any problem on modern hardware that it's default platform is pentium4.
Regards
-
The i386 repository went away long ago, so has to be i686. Shouldn't cause any problems, try installing it after building it. Or build both.
-
Hello
I modified DataSeeker based in the suggestions. And I also wanted to go deep on the icons creations.
But I'm not sure if I made it the optimal way to create the readme and copying icons.
DATASEEK_READ:WPProgram|Read Me|<DATASEEK_FOLDER>|EXENAME=e.exe;PROGTYPE=PROG_PM;PARAMETERS=((%{_datadir}/doc/%{name}-%{version}/DataSeek.txt));OPEN=RUNNING
DATASEEK_LIC:WPProgram|License|<DATASEEK_FOLDER>|EXENAME=e.exe;PROGTYPE=PROG_PM;PARAMETERS=((%{_datadir}/licenses/%{name}-%{version}/COPYING));OPEN=RUNNING
Any suggestion are welcome?
Regards
Note: I reuploaded the files with some changes.
-
Here I'm trying mp3gain.
No icon creation is done or needed, i think.
I guess this port is "pentium4"
Regards
-
And the next one AACGAIN.
-
Here goes cdda2wav
-
Have you looked at the build flags before deciding that all the above are P4? And does the license require source?
-
Hi Dave
Some came with source code and some don't. Where should I put the source code in the FHS?
Should the source code be unziped there, or just like a zip file?
Regards
-
The usual is to have a source RPM which is built while building the package. If the source is in a stable place, simply putting a link to the source should be good enough.
-
Hi Dave
Some came with source code and some don't. Where should I put the source code in the FHS?
Should the source code be unziped there, or just like a zip file?
Regards
If you have the source code (e.g. as archive file) i think that you can put it under :
(something I do when using @unixroot)
all .zip;.tar;.wpi to /usr/src/<name of package>
-
Hi Dave
Some came with source code and some don't. Where should I put the source code in the FHS?
Should the source code be unziped there, or just like a zip file?
Regards
If you have the source code (e.g. as archive file) i think that you can put it under :
(something I do when using @unixroot)
all .zip;.tar;.wpi to /usr/src/<name of package>
Thanks. I will try later if "%{_usrsrc}" works for us.
-
Hello
Just a question here about cdda2wav.exe, (it is compiled on 2007-08-24), it references to libc05.dll (which is included). Do you think it will be desirable to recompile it to reference the libc that is included in ArcaOS ?
cdda2wav is included in cdrtools, right?
- https://sourceforge.net/projects/cdrtools/
Regards
-
Ideal would be recompiling it if easy, cdrecord used a weird build system that only supported EMX.
Another idea is to package libc05 separately and have a dependency.
-
Hello
Just a question here about cdda2wav.exe, (it is compiled on 2007-08-24), it references to libc05.dll (which is included). Do you think it will be desirable to recompile it to reference the libc that is included in ArcaOS ?
cdda2wav is included in cdrtools, right?
- https://sourceforge.net/projects/cdrtools/
Regards
Hi Martin,
ArcaOS 5.1.1 has cdrtools 3.01.1 package installed (RPM) but no cdd2wav.exe into it while cdda2wav is available into a different cdrtools build and can be used as standalone installation
Having cdda2wav available as a standalone RPM installation package is then the best option.
Note: If you are going to recompile it, I'm ok to give it a test, using cdda2wav.exe under AVxCAT
-
Hello
Do you think it will be good to do an extra things to the executables? I noticed that a lot of the .exe and .dll does not has bldlevel information.
- Will be it be ok to add that information on the exe/dll using AddToFile (https://www.os2world.com/wiki/index.php?title=AddToFile) ?
- would that violates the sacrosanctity of the binary :) ?
- or is it too much OCD ?
I know that it may only be a nice to have, but not completely necessary.
Regards
-
You understand that you have to rebuild the binaries after patching the makefiles to use Addtofile? Also I just noticed the license doesn't allow hosting the script on any servers so it would have to be downloaded by anyone rebuilding the binary.
Other then that, adding bldlevel info seems a good idea.
-
Hi
You understand that you have to rebuild the binaries after patching the makefiles to use Addtofile? Also I just noticed the license doesn't allow hosting the script on any servers so it would have to be downloaded by anyone rebuilding the binary.
Other then that, adding bldlevel info seems a good idea.
I guess I didn't understand it right. I thought that "AddToFile" changed the .exe to include the bldlevel information, and that modified exe was going to be included on the RPM. I didn't know that the binary had to be rebuild. Or that every user had to download "AddToFile" for it to work.
Regards
-
Hello again
For example, here I attach a file I changed with AddToFile.
I run:
- AddToFile.cmd aacgain.exe,option AAC file normalizer,BLDLEVEL,Glen Sawyer,1.9.0,AAC file normalizer,Fixpack,Asd
[C:\HOME\MARTIN\DOWNLOADS\AACGAIN-BLDLEVEL]bldlevel aacgain.exe
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#Glen Sawyer:1.9.0#@##1## 23 Mar 2025 20:30:58 ARCAOSVM :
Asd:::0::Fixpack@@AAC file normalizer'
Vendor: Glen Sawyer
Revision: 1.09.0
Date/Time: 23 Mar 2025 20:30:58
Build Machine: ARCAOSVM
ASD Feature ID: Asd
FixPak Version: Fixpack
File Version: 1.9
Description: AAC file normalizer'
What I would like to do is to keep the same file date of the compile date. Any suggestions there?
Regards
-
Not every user has to download Addtofile.cmd, just any developer wanting to build the package. Should be able to design the makefile to not error out if Addtofile.cmd isn't available too. Not sure how.
-
I apologize, seems you can add the bldlevel info to a binary. Looks like the script would need to be extended to add a different date then current.
-
No problem.
I just need to understand what should be on:
- Build Machine: Maybe I should put that on blank, since I don't know the build machine. But I don't know how to do that with AddToFile yet.
- ASD Feature ID: I don't know what is this.
- Fixpack: The OS/2-ArcaOS fixpack level? or I just leave it blank? I also don't know the fixpack level of the build machine.
- Date: I need to find how to put the older compile date with AddToFile and also try not to change the file date.
Regards
-
For build machine, blank or perhaps something like generic? Don't know what asd is either. I abuse the fixpak to add a version number, eg v2.5.
You can use touch to change the date and time of a binary or any file. The -r parameter is interesting. touch --help.
-
There are some bldlevel information when added to an .exe leads to strange things when the exe is loaded by OS/2. Although strictly correct regarding Stevens notes about bldlevel it's yet unknown why f.i. sometimes the menu is not loaded by OS/2. Or even worse some program refuses to start with some bldlevel information.
Summing up my experience with bldlevel infos I made with my projects, if the developer who extensively tests the program don't add a bldlevel info I wouldn't add it later. It may be dangerous and maybe more harm then help.
-
Hello Andi B.
There are some bldlevel information when added to an .exe leads to strange things when the exe is loaded by OS/2. Although strictly correct regarding Stevens notes about bldlevel it's yet unknown why f.i. sometimes the menu is not loaded by OS/2. Or even worse some program refuses to start with some bldlevel information.
Summing up my experience with bldlevel infos I made with my projects, if the developer who extensively tests the program don't add a bldlevel info I wouldn't add it later. It may be dangerous and maybe more harm then help.
Thanks for the point of view and recommendation. It is a good warning and I will like to test what kind of program can provide problem to add the bldlevel information later. I will try some command line tools first and post back to see if we can get an issue.
Regards