Author Topic: YUM and RPM repositories - unable to add and save, why?  (Read 16098 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
YUM and RPM repositories - unable to add and save, why?
« on: February 10, 2018, 08:32:18 pm »
Let me say the following right off the top: my original install of YUM, RPM and ANPM was using the i686 platform. In that configuration everything appeared to work fine, but I would occasionally run into problems with various installs (such as the Git package for example) where no explanation for the failure was available.

Given that I am running this on an AMD Phenom II X6 CPU, and the fact that big applications like Firefox are being released as 'pentium4' platform I decided to "do the prayer" and convert my platform. Yes, it is a well recognized fact that this is really more about luck then following a prescribed process.

However, having reached out to the ANPM guys I got some good hints on what MIGHT work. I accepted that and off I went to experiment.

Alright...so the end result now is that I appear to have a working pentium4 platform install. ANPM starts up fine and produces a listing of all my installed packages, however, I do not see any repositories. Worse yet, attempting to add a repository (such as netlabs-rel) simply does not work. Nothing shows up in ANPM, no file is created in the \etc\ym\repos.d directory, nuthin'!!!! Conversely, putting a file directly into the \etc\yum\repos.d directory is simply not recognized by ANPM or YUM for that matter.

So for example, here is what I get:

[G:\]yum repolist
Config time: 0.076
Yum Version: 3.2.27
COMMAND: yum repolist
Installroot: /@unixroot
Setting up Package Sacks
repolist: 0

I'm at a loss at this point in time. What are the variables that control where YUM stores the repo files? What else should I look at?

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #1 on: February 10, 2018, 08:49:14 pm »
Hi Dariusz

Why change to pentium4 if i686 worked fine? - I doubt it makes any difference as to whether an app will install and run.

Are the packages arcanoae-rel and netlabs-rel showing in either Installed or Available?


Regards

Pete

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #2 on: February 10, 2018, 09:00:41 pm »
Quote
Given that I am running this on an AMD Phenom II X6 CPU, and the fact that big applications like Firefox are being released as 'pentium4' platform I decided to "do the prayer" and convert my platform

But, i686 is the proper platform for that machine. Why would you want to change? Pentium 4 is for Intel Pentium 4 machines. Firefox is also available for i686 platform. Use the proper one, and it will all work better.

Hopefully, you have a backup that you can restore, because trying to fix the problem, that you have caused, will likely be difficult, at best.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #3 on: February 10, 2018, 10:08:55 pm »
Hi Doug!

Quote
Given that I am running this on an AMD Phenom II X6 CPU, and the fact that big applications like Firefox are being released as 'pentium4' platform I decided to "do the prayer" and convert my platform

But, i686 is the proper platform for that machine. Why would you want to change? Pentium 4 is for Intel Pentium 4 machines. Firefox is also available for i686 platform. Use the proper one, and it will all work better....

But that is actually not correct.

Here is a great link (https://myonlineusb.wordpress.com/2011/06/08/what-is-the-difference-between-i386-i486-i586-i686-i786/ ) that links the RPM architecture naming conventions to the CPU family releases.

To summarize:

i386 – Intel i386/80386 (in 1985) or AMD386 / AM386
i486 – Intel i486/80486 (Pentium 4 /Pentium Pro) or AMD486 / AM486
i586 – Intel Pentium 5 (ly) or AMD-K5
i686 – Intel Pentium 6 (ly) or AMD-K6
i786 – Intel Pentium 7 (ly) or AMD-K7

...and the Phenom processors are newer than the Athlon CPUs which were the K7 family, therefore, on my hardware I should be aiming to run the 'pentium4' platform, besides, I am already planning for the Ryzen deployment next...so why get stuck with the i686 stuff where vast majority of the multimedia instructions are not supported? (think of that pesky FF/YouTube video playback problem...)

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #4 on: February 11, 2018, 12:44:38 am »
Hi Dariusz, there's 2 main things to consider when trying to figure out the closest CPU choice to what you're actually using, features and instruction ordering.
Feature wise, the P4 (RPM is only targeting the first generation P4) is ahead of i686 as it supports MMX, SSE and I believe SSE2, which are known as simd instructions. For regular programs, these usually don't matter, except programs that do a lot of floating point math may use SSE2 instead of i387 instructions depending on compiler settings. Note most programs don't use much in the way of floating point math. Multimedia apps, including Firefox also benefit from the simd instructions but most all dynamically check what CPU you have and enable the instructions. They often also have hand rolled assembly code to use the simd instructions and even where simd instructions are used by other stuff such as intl support in Firefox, both paths are compiled including SSE2 (-msse2 is the GCC option) and a runtime check decides which path to take. Note newer versions of Firefox (53+) require SSE2 now with a minimum CPU requirement of a Pentium M.
Instruction ordering is more important. Most all CPU's are pipelined and do speculative execution. If the instructions are ordered correctly, the CPU can dispatch more instructions per cycle and have less chance of needing to flush the pipeline and refill it. Most all Intel CPU's are descended from the i686 while the Netburst architecture was a completely different beast which used very different preferred instruction ordering. It's one of the reasons that generally a P4 was so slow compared to a P3. At one point I had a P4D running at 2.8 MHz and swapped the CPU for a 1.86Mhz C2D and it was at least 50% faster (and used half the power).
AMD processors use instruction ordering much closer to the i686 and for this reason i686 is the better choice compared to P4 (Netburst) for most programs and most multimedia apps including Firefox playing youtube videos will still use most all simd instructions that your CPU supports.
You should be able to find an open source CPU benchmark and test by compiling with various CPU architectures.
Really it would be nice if RPM supported a few more architectures such as the Pentium M or newer and RPM was a bit smarter about realizing that they're all i386 variants and allowed more mix and match.
« Last Edit: February 11, 2018, 12:46:29 am by Dave Yeo »

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #5 on: February 15, 2018, 05:51:39 am »
Hey Dave!

...You should be able to find an open source CPU benchmark and test by compiling with various CPU architectures...

Yeah, I understand that there are significant differences between something like the pentium4 and pre-CPUs. Heck, I would imagine that the massive pipeline depth on the p4 alone has a significant bearing on what optimizations the compiler can do. The P4 architecture was meant to enable very fast clock speeds, 4HGz and higher. The challenge with something like the AMD Phenom family is that they are not as deep, so certainly the code compiled for p4 will be sub-optimal...however, w/o measuring this, as you said, it is really hard to know.

Alright...so off to work I went...plugged away until I found some open source benchmarks, I pulled the Linux specific sources in hopes of this getting me a relatively closer migration path. I have a vanilla install of the OS/2 Toolkit along with the RPM gcc (4.9.2). The issue I've ran into is that various header files are missing in the OS/2 install.

For example: sysinfo.h, not present at all, not in the GCC, not the toolkit, nor even the IBMCPP environment.

In such cases (and I did spend a chunk of time looking at this prior to posting here), what is the correct approach to pursue? Meaning, do I simply find such a file and toss it onto my box here?

I had just plugging the holes without really understanding the bigger env/configuration picture.

As always, thanks for the insights!

EDIT: As best as I can tell this should be in the gnulib package...but I see nothing like that out there, closest is glib2-devel, but that does now show the sysinof.h file.
« Last Edit: February 15, 2018, 06:10:44 am by Dariusz Piatkowski »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #6 on: February 15, 2018, 08:02:42 am »
Searching for sysinfo.h results in
Quote
sysinfo struct in linux/kernel.h
so whatever code uses it won't compile on OS/2 without porting or may be unneeded. Better to search for a cross platform benchmark.
Quickly looking I found this, http://www.math.utah.edu/~mayer/linux/bmark.html which compiles fine with a bit of makefile editing. Change the CFLAGS line to remove -static and add -Zomf for a quick compile. Should have the targets adjusted by adding .exe and the clean rule changed from /bin/rm to rm and possibly other changes.
Some of my results are low so possibly needs some code changes, perhaps something is overflowing. There's a more up to date port here, https://www.freshports.org/benchmarks/nbench/ if you can figure out how to download the source.

Quote
H:\tmp\nbench-byte-2.2.3>nbench.exe

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          652.56  :      16.74  :       5.50
STRING SORT         :          69.906  :      31.24  :       4.83
BITFIELD            :      3.7866e+08  :      64.95  :      13.57
FP EMULATION        :          103.23  :      49.53  :      11.43
FOURIER             :           13282  :      15.11  :       8.48
ASSIGNMENT          :          23.981  :      91.25  :      23.67
IDEA                :          3222.6  :      49.29  :      14.63
HUFFMAN             :          1618.9  :      44.89  :      14.34
NEURAL NET          :          24.707  :      39.69  :      16.70
LU DECOMPOSITION    :          1091.8  :      56.56  :      40.84
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 44.389
FLOATING-POINT INDEX: 32.367
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : OS/2 1
C compiler          : gcc version 4.9.2 (GCC)
libc                :
MEMORY INDEX        : 11.579
INTEGER INDEX       : 10.714
FLOATING-POINT INDEX: 17.952
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #7 on: February 15, 2018, 03:58:40 pm »
...Quickly looking I found this, http://www.math.utah.edu/~mayer/linux/bmark.html which compiles fine with a bit of makefile editing...

Ahhh...awesome, I found the various write-ups on nbench, but none of my searches led me to a source, but yeah, it seems like that benchmark has a reasonable mix of what it does.

Alrigh, so next questions: what are you using for make?

I see the following options available through YUM:

Available Packages
automake.noarch                            1.14.1-3.oc00             netlabs-rel
cmake.pentium4                             3.7.0-2.oc00              netlabs-rel
cmake-data.noarch                          3.7.0-2.oc00              netlabs-rel
cmake-debuginfo.pentium4                   3.7.0-2.oc00              netlabs-rel
cmake-doc.noarch                           3.7.0-2.oc00              netlabs-rel
cmake-gui.pentium4                         3.7.0-2.oc00              netlabs-rel

kbuild-make.pentium4                       1:0.1.9998-9.oc00         netlabs-rel

What I know about cmake is that it's really not a make replacement but rather a project builder, which in effect creates the actual makefile that is then used.

So basically either the toolkit make or kbuild...advice as to which one I need to pursue?
« Last Edit: February 15, 2018, 04:05:30 pm by Dariusz Piatkowski »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #8 on: February 15, 2018, 04:23:26 pm »
kbuild-make is gnumake and the usual one to use.

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #9 on: February 16, 2018, 04:02:39 pm »
I just now had a chance to view the Arca Noae Package Manager.  I am impressed.  It makes it so easy to update and install RPM.  Great job to the developers.  However, I encountered one problem.  It was while I was messing with both DVD Tools and RSJ writer I encountered the problem.  This is with the latest version of YUM.

I deleted the CDRTools 3.01.1-1 using YUM.  After trying various thing, I went to reinstall the program.  When accessing the DVD for the RPM, it was the one package it couldn't find even though it was still on the DVD.  I then tried doing it with FM/2 through association.  YUM would start, show the file, I would select it to install and it went through the motions like it was installed.  However, when the depository reappeared, no CDTools.

Finally I went to Quick Install.  Typed in "YUM install cdrtools 3.01.1-1"

It downloaded and installed without a problem and now appears in the package manager.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #10 on: February 16, 2018, 04:13:31 pm »
Alright...got some results to toss at you guys!

So first thing first, Dave, I see what you mean about possible overflow, the GCC warning is there, but as I know very little about OS/2 C/C++ coding I can not tell whether this declaration is a problem. Worse yet, the makefile is attempting to build pointer.h dynamically, but it is clearly missing some of the underlying OS/2 implementations:

During compilation I get the following back:

if [ "4" = `./pointer` ] ; then touch pointer.h ;\
else echo "#define LONG64" >pointer.h ; fi
./pointer: 1: ./pointer: Syntax error: word unexpected (expecting ")")
G:/usr/bin/sh.exe: 1: [: =: argument expected

That leads me to believe that the './pointer' is some sort of a linux/gnu? cl utility...but searching on this just brings up a mountain of results on the C/C++ pointer topic instead...LOL

Needless to say, pointer.h is created as:
#define LONG64

...and so AFAIK this is telling the code that the local compilar supports 64-bit long...does it in our case? I think not given that we are in a 32-bit OS...?

#ifdef LONG64
#define MAXPOSLONG 0x7FFFFFFFFFFFFFFFL
#else
#define MAXPOSLONG 0x7FFFFFFFL
#endif

Especially in light of the comment in the main code:

/* is this a 64 bit architecture? If so, this will define LONG64 */
#include "pointer.h"

...I actually think that pointer.h should be commented out. So that is what I'm working on now, the 32-bit version of this benchmark I suppose???

Once I finish that and have a decent set of results I'll post an update!

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #11 on: February 16, 2018, 05:17:02 pm »
Hmm, here I get,
Code: [Select]
gcc  -DLINUX  -s -Zomf -Wall -O3\
        -o pointer pointer.c
rm -f pointer.h
if [ "4" = `./pointer` ] ; then touch pointer.h ;\
else echo "#define LONG64" >pointer.h ; fi
with a correct empty pointer.h. The build system builds pointer.exe here which outputs 4.
I get one harmless warning,
Code: [Select]
gcc  -DLINUX  -s -Zomf -Wall -O3\
        -c nbench1.c
nbench1.c: In function 'DoNNET':
nbench1.c:3149:7: warning: variable 'errorcontext' set but not used [-Wunused-but-set-variable]
 char *errorcontext;
       ^

Here's my Makefile patch, and I created a repository, https://github.com/dryeo/nbench-byte. Here's a basic binary as well, seems to work with the attached NNET.DAT in the same directory.

« Last Edit: February 16, 2018, 06:07:18 pm by Dave Yeo »

TeLLie

  • Full Member
  • ***
  • Posts: 226
  • Karma: +11/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #12 on: February 16, 2018, 09:58:24 pm »
Hi Dave,

i get:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :
_fmutex operation failed:  LIBC Heap request
 
Killed by SIGABRT
pid=0x0586 ppid=0x0061 tid=0x0001 slot=0x00ca pri=0x0200 mc=0x0002 ps=0x0017
C:\HOME\DOWNLOADS\NBENCH.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

_fmutex operation failed:  LIBC Heap request
 
Killed by SIGABRT
pid=0x0586 ppid=0x0061 tid=0x0001 slot=0x00ca pri=0x0200 mc=0x0003 ps=0x0017
C:\HOME\DOWNLOADS\NBENCH.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.


Will try to compile myself to...

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #13 on: February 16, 2018, 10:11:03 pm »
Dave,

I think I see the root cause of my problem.

I took your makefile, executing it gets me the following:

===
[G:\CODE\SOURCE\BENCHMARKS\NBENCH]make
gcc -s -Zomf -Wall -O3    pointer.c   -o pointer
ilink.exe: No such file or directory
make: *** [pointer] Error 1
===

'ilink.exe' does exist, just not anywhere in the PATH since it is part of the IBM C/C++ toolset I have installed on my machine, so I am not sure how this gets pulled in to the GCC process?

If on the other hand I remove the '-Zomf' from the 'CFLAGS = -s -Zomf -Wall -O3', then I can successfully compile and build the final nbench.exe, but the pointer EXE is never created, or rather, what is created can not be executed within an OS/2 session and subsequently I see how the makefile macro fails to build a proper pointer.h file.

HOWEVER

If I modify the makefile slightly and do the following (change in BOLD):

===
pointer.h: pointer Makefile
   $(CC) $(MACHINE) $(DEFINES) $(CFLAGS)\
      -o pointer.exe pointer.c
   rm -f pointer.h
   if [ "4" = `./pointer` ] ; then touch pointer.h ;\
   else echo "#define LONG64" >pointer.h ; fi
===

..then pointer.exe is created successfully, it runs during the build process and puts a '4' into pointer.h file.

All of that begs the question: what the heck is that '-Zomf' switch???

Sorry, unless I am missing the obvious I am not finding the answer out there. I most often try the following GCC sites for info:

1) https://gcc.gnu.org/
2) https://gcc.gnu.org/onlinedocs/
3) https://www.gnu.org/manual/manual.html


Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: YUM and RPM repositories - unable to add and save, why?
« Reply #14 on: February 17, 2018, 12:42:00 am »
Hi Dariusz, the -Zomf and all -Z* options are OS/2 specific, in the case of -Zomf, it converts the aout object files that GCC produces into OMF format which is OS/2's native format. With OMF object files we use the native linker to link, which works better then our ancient LD port, especially for DLL's. (and was originally the only way to build DLLs with GCC)
You're probably missing the wl package, gcc-wlink rpm, which I believe will add the correct environment variables to config.sys to use wl.exe (wlink with some fixes to handle our debug data). Run emxomfld.exe to see the variables needed.You can also add ilink to your path, might need some dpath additions as well as INCLUDE additions.
Without -Zomf, you can use the -Zexe switch will build a pointer binary and a pointer.exe binary which the pointer binary will point to.

Hi Tellie, interesting. Machine too quick? Perhaps try debugging or just link in libcx, add -g and -Zmap and see if it gives a trp file. All I did was adjust the Makefile quickly, probably wouldn't hurt to add -Zbin-files to the CFLAGS as well.