sgidevnet / sgug-rse Goto Github PK

This package creates /usr/sgug/lib/rpm/macros.d/macros.pybytecompile .

This macro contains
32 [[ "%1" =~ " -" ]] && echo "ERROR py_byte_compile: Path to interpreter should not contain any arguments" >&2 && exit 1 \

mksh cannot interpret the =~ and will fail.

This prevents glib2 from building.

The original libjpeg in rse is actually libjpeg-9c.

It is currently used (depended on) by a number of packages - and was in place because libjpegturbo needs cmake to build (which we historically did not have back in the mists of time).

Someone needs to do the big painful job of switching over to libjpegturbo and then fixing all the packages currently linked against the older library to use the newer one.

Everything will need a version bump that is changing, and everything (going forward) should depend on libjpegturbo to avoid issues with "I installed a newer emacs and now it doesn't start" etc.

This is not a simple change.

First seen with pidgin, then tested with gtk-demo and a small sample gtk2 app.

The app will crash immediately, sometimes drawing the initial window.

The same app will work properly via remote.

Pidgin has run locally on a Onyx4 system that runs XFree86.

[sgugshell esp@OCTODAD ~]$ infocmp
117013:infocmp: rld: Fatal Error: attempted access to unresolvable symbol in infocmp: _nc_read_entry2
[sgugshell esp@OCTODAD ~]$ ldd `which infocmp`
        libtic.so  =>    /usr/sgug/lib32/libtic.so
        libtinfo.so  =>  /usr/sgug/lib32/libtinfo.so
        libm.so  =>      /usr/lib32/libm.so
        libc.so.1  =>    /usr/lib32/libc.so.1
        libgcc_s.so.1  =>        /usr/sgug/lib32/libgcc_s.so.1

Everything installed from the binary distributions. I could try rebuilding to see if this goes away?

The nettle upgrade done in the SP releases included the install/links for a backwards compatibility library.

With real 0.0.6 we no longer need that extra library, so it can be deactivated in the .spec

It's the "transfiletriggerin" causing it.

No deeper info for the moment, my investigations weren't fruitful because there's a signal handler in RPM that's causing GDB to be unaware of the stack when the crash happens.

Will need proper instrumentation (sticking printf in there) and lots of patience.

Can be reproduced outside of shared-mime-info by having a .spec file with all three "post" + "trigger" handlers.

See the outstandingchecklist.html and keep it up to date with progress.

e.g. Re-enable Requires: and BuildRequires: as appropriate in the .spec files.

Any package with a daemon that needs to set up a user or group can not currently do so.

This is due to IRIX not having the user* and group* family of programs.

I'm currently porting user from NetBSD which will provide this missing functionality.

Running the ssh client gives warnings about unsupported option "gssapi". This is probably a config file issue.

The openssh-server is currently not installable - and in fact I've done no work to ensure it's setup correctly with a user or that the "right thing" is done vis-a-vis /etc/init.d/ scripts.

Caution: Having the existing RPM script install / modify things outside of the /usr/sgug prefix is something that needs to be discussed further - because it means

(a) It's a pain to build the self hoster if it includes files outside of the prefix
(b) Really we want any RPMs that do this kind of thing to be installed after the self-hoster is in place - so that the correct post/pre triggers are executed for user creation / permissions etc.

This will avoid conflicts with system software / other binaries.

Idea is to set a "default" rpath in the GCC itself, probably via modifying the gcc specs file.

There's a few packages I manually added rpath to that will need this reverting.

There's still two packages I'm aware of that are generated but cannot be installed (bad or missing deps)

openssl-perl
texinfo-tex

These should be commented out in the %files section - and then in the %install section at the end the related files should be removed.

As above,

Change this tool to do nothing - so we don't have to rewrite the places where it's used.

We could replace the "real" binary with /bin/true, for example.

It's not a big deal at the moment because we still use/have "sgugshell" so LD_LIBRARYN32_PATH works its magic.

In the longer future, we want our binaries to able to run without needing LD_LIBARARYN32_PATH - and that means setting the RPATH.

TL;DR: trying to build glib2 on my Octane fails because python 3.8wip is missing compileall2. Attempting to build 3.7.7 results in a dependency error on desktop-file-utils, which in of itself requires glib2 to build. Commented out the dependency to see what happens, waiting for build results...

Can't find iostreams library anywhere. Headers are in place, though.

e.g. fc13 /usr/share/info
sgugrse /usr/sgug/info

Seems we are missing a /usr/sgug/share/info directory for this stuff to live in.

Requires a big-old-rebuild everything release to fix it.

We're missing the GDB package.

Also, regular Fedora automagically extracts package debug info so that GDB can use it. The auto-extraction may never work (the elftools under rpm were hacked up just enough to get rpm working).

git has issues reading your RSA keys to perform remote operations via SSH. Probally related to the sshd issue with reading... keys.

dillera@challenge ~/code $ export GIT_TRACE=1
dillera@challenge ~/code $ GIT_SSH_COMMAND="ssh -vvv -i ~/.ssh/github_rsa -o 'IdentitiesOnly yes'" 
dillera@challenge ~/code $ git clone [email protected]:dillera/sgug-rpm-tools.git
15:23:45.955695 git.c:439               trace: built-in: git clone [email protected]:dillera/sgug-rpm-tools.git
Cloning into 'sgug-rpm-tools'...
15:23:46.017538 run-command.c:663       trace: run_command: unset GIT_DIR; ssh [email protected] 'git-upload-pack '\''dillera/sgug-rpm-tools.git'\'''
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
dillera@challenge ~/code $ 

Narrowing down- lets just try to validate SSH into github...

dillera@challenge ~/code $ ssh -T [email protected]
... bunch of stuff
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /usr/people/dillera/.ssh/id_rsa RSA SHA256:GwcrADxsvI1nN3EIG5O6Z42MBiDqtVX/Bb6VloKo8eU
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: /usr/people/dillera/.ssh/id_rsa RSA SHA256:GwcrADxsvI1nN3EIG5O6Z42MBiDqtVX/Bb6VloKo8eU
debug2: Load key "/usr/people/dillera/.ssh/id_rsa": Broken pipe
debug1: Trying private key: /usr/people/dillera/.ssh/id_dsa
debug1: Trying private key: /usr/people/dillera/.ssh/id_ecdsa
debug1: Trying private key: /usr/people/dillera/.ssh/id_ed25519
debug1: Trying private key: /usr/people/dillera/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).

This should probally not be happening:

debug2: Load key "/usr/people/dillera/.ssh/id_rsa": Broken pipe

More to come.

Here is a place where @HardwareAbstractionLayer and @mach-kernel can add logs and other info about the issues attempting to build the latest cmake in wip.

Please check you have the latest RPMs installed from the sp5. Maybe it helps to try and build cmake from the SRPM, too.

Be aware - building cmake is very RAM hungry - some of the individual links can use up to 800MB - so if you have "-j 3" you'll need a minimum of 2 GB of RAM. My build octane has 5GB, for info.

Please ensure you're using sgugshell for the build, and that you are not using any additional scripts that modify the environment - so no modifications of LD_LIBRARYN32_PATH, PATH etc.

What I need:

(1) Where is it getting to? Can you dump the logs from a build into a gist and link it here?
(2) What have you done to investigate why it stops? Any additionally info might help in tracking down the issue.

Thanks

(Maybe this is linked to #72 ?)

After rebuilding python3.7 and deps all weekend I see the same issue with libxml2 as I did earlier:

make[4]: Entering directory '/usr/people/edodd/rpmbuild/BUILD/libxml2-2.9.9/py3/python' /usr/sgug/bin/sh ../libtool --tag=CC --mode=link mips-sgi-irix6.5-gcc -O3 -g -module -avoid-version ../libxml2.la -L -lpython3.7m -lsock et -lnsl -lintl -ldl -lm -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -Wl,-rpath -Wl,/usr/sgug/lib32 -Wl,-rpath -Wl,/usr/lib32 -o libxml2mod.la -rp ath /usr/sgug/lib32/python3.7/site-packages libxml.lo libxml2-py.lo types.lo libtool: error: require no space between '-L' and '-lpython3.7m'

In ~/rpmbuild/BUILD/libxml2-2.9.9/py3/python/Makefile I see
PYTHON_LIBS = -L$(echo /usr/sgug/lib32 | sed s#/usr/sgug#$(installed_prefix /usr/sgug/bin/python3.7m-mips-config)#) -lpython3.7m -lsocket -lnsl -lintl -ldl -lm .

It seems that during build, it's attempting to exec installed_prefix /usr/sgug/bin/python3.7m-mips-config in a subshell and failing.

I'm unable to determine where 'installed_prefix' should be. I don't see it in RSE, and I don't have it in /usr/sgug (or prior versions of). However, I do see it named as a function in /usr/sgug/bin/python3.7m-mips-config .

Am I reading the Makefile wrong? Is sed not supposed to exec that? How is this supposed to work?

Need commenting out in the .spec.

(Copy pasta from didbs issue number 6)

Occasionally make is failing due to "duping jobs pipe".

It possibly open file limit or some other issue. Needs deeper investigation, might be related to IRIX select not working quite exactly like regular select.

Issue reproduced with jobserver_pre_acquire - looks like make_job_rfd returns -1 from make_job_rfd() call.

This is EINTRLOOP(job_rfd, dup(job_fds[0])) - at a guess irix occasionally return EMFILE for too many files or something like that.

And so I have my first occurence of this with the logging in place.

In posixos.c, jobserver_pre_acquire:

DH job_fds[0]=3 job_rfd=-1 and errno=2
DH job_rf_val=-1

Which is actually failing deeper down in the make_job_rfd code - which in turn is a call to EINTRLOOP that isn't giving back what it should.

Another one:

DH job_fds[0]=3 job_rfd=-1 and errno=9
DH job_rf_val=-1
make: *** duping jobs pipe #2: Bad file number

Massive hit this too:

DH job_fds[0]=6 job_rfd=-1 and errno=9
DH job_rf_val=-1
make[2]:  duping jobs pipe #2: Bad file number.  Stop.
make[2]:  Waiting for unfinished jobs....
  GEN      sys/time.h

Seen with docbook5-style-xsl, rpm - any scripts that use /usr/bin/env TOOL get rewritten to /usr/bin/TOOL.

It would be nice to rewrite these to /usr/sgug/bin/TOOL - and would fix a regression seen with more recent rpm macros versus just using the original /usr/bin/env TOOL.

$ gdk-pixbuf-query-loaders |grep png [sgugshell edodd@blue RPMS]$

$ sudo rpm -qa|grep gdk-pixbuf gdk-pixbuf2-2.40.0-3.sgugprerelease0.0.6.mips gdk-pixbuf2-modules-2.40.0-3.sgugprerelease0.0.6.mips gdk-pixbuf2-xlib-2.40.0-3.sgugprerelease0.0.6.mips gdk-pixbuf2-devel-2.40.0-3.sgugprerelease0.0.6.mips gdk-pixbuf2-tests-2.40.0-3.sgugprerelease0.0.6.mips gdk-pixbuf2-xlib-devel-2.40.0-3.sgugprerelease0.0.6.mips

$ rpm -qpl gdk-pixbuf2-*|grep loader /usr/sgug/bin/gdk-pixbuf-query-loaders /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache /usr/sgug/share/man/man1/gdk-pixbuf-query-loaders.1.gz /usr/sgug/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-loader.h /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-gif.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-icns.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ico.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jasper.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-pnm.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-qtif.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tga.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xbm.so /usr/sgug/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so

The fedora package chkconfig is in fact only used for the sub-package output RPM it generates - alternatives.

Move this over to the correct package, stop generation of the other bits.

For unknown reasons as of 0.0.1alpha gcc + binutils revert to dynamically linking in libgcc_s.so all the time, which is a pain.

Using the -static-libgcc doesn't do the trick - and in fact check most autoconf projects and you'll notice that it doesn't detect gcc as being able to static link at all during discovery.

Yep, slipped through the cracks.

Bonus is you get to experience rebuilding an RPM package :-)

The master version of the packages/pax-utils.spec re-includes the missing tool - and can be built if you have the SRPMS installed:

cd ~/rpmbuild/SPECS
rpm -ivh ../SRPMS/pax-utils*.src.rpm
cp ~/sgug-rse.git/packages/pax-utils/SPECS/pax-utils.spec ./
rpmbuild -ba pax-utils.spec --nocheck

Then change to root install it:

su -
cd ~user/sgug-rse.git
./sgugshell.sh
rpm --reinstall -ivh ~user/rpmbuild/RPMS/mips/pax-utils*.rpm
exit

In the original .spec there is a call out to /usr/sbin/groupadd to add the screen group.

It's currently commented out for Irix - we don't have equivs in Irix yet (see the sshd bug #15 where these things are needed too.)

After completing the README for 0.0.5, on a fresh system, the current SP for devs' rpms do not install as described.

sudo rpm -Uvh noarch/*.rpm mips/*.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] package libtool-2.4.6-32.sgugbeta.mips is already installed package libtool-ltdl-2.4.6-32.sgugbeta.mips is already installed package libtool-ltdl-devel-2.4.6-32.sgugbeta.mips is already installed

Installing via sudo rpm -Uvh --reinstall noarch/.rpm mips/.rpm shows many conflicts between the installed package's files and its point-release update:

file /usr/sgug/bin/autoconf from install of autoconf-2.69-33.sgugbeta.noarch conflicts with file from package autoconf-2.69-32.sgugbeta.
noarch

@jupo42 found one out the gate - the default editor for visudo is missing (since the package isn't installed yet). Workaround == set $EDITOR to something sensible before launching it.

rpmbuild makes use of the libmagic library - both linked directly into rpmbuild and also via the file executable from the /usr/sgug/lib/rpm/brp-* scripts.

Under IRIX this library has very slow matches for certain file types - enough that out of the box running file on a single unlucky file type can take over 2 seconds, sometimes more.

Initial investigation suggests that it's not the actual lookup/running analyser that is the problem - the problem is created during the building of the /usr/sgug/share/misc/magic.mgc compiled magic database.

The magic database seems to mostly be made correctly (regarding endianness issues) - but examining a like-for-like comparison against a native linux build shows that different paths are taken when matchers are used from a compiled database.

I'm currently looking at this - it's the source of very slow rpmbuild times for certain packages (that have the slow file types). The existing file package in sgug-rse already has a few of the slow matchers commented out, but a proper fix will require looking into why the compilation of the database breaks things.

Using the existing gdb in rse has outstanding issues to be looked into:

(1) Spurious signals arrive that seem unhandled by gdb
(2) Applications that use pthreads seem to cause issues when attempting to debug them

So far, this issue is difficult to pin down and will require deeper scenario testing to find out the cases in which the errors / problems are seen.

e.g.

building and linking a simple executable + single library, main calls a function in the shared lib where pthread_create is done with a simple function executed. Putting a break inside the func called in the library == all working!

The breakpoint is hit, can inspect the vars inside the func.
The stack is a wee bit strange, but possibly correct due to the launch of the thread:

Starting program: /usr/people/dan/Temp/testpthread/sgug-rse/./testprog 
Main begin.

Breakpoint 1, doit (arg=0x0) at testlib.c:8
8         printf("doit\n");
(gdb) where
#0  doit (arg=0x0) at testlib.c:8
#1  0x0c05d480 in _SGIPT_pt_start ()
    at /xlv86/patches/7202/work/eoe/lib/libpthread/libpthread_n32_M3/pt.c:813
#2  0x00000000 in ?? ()
(gdb) list
3       #include <stdio.h>
4       #include <string.h>
5
6       void* doit( void * arg )
7       {
8         printf("doit\n");
9
10        return NULL;
11      }
12
(gdb) print arg
$1 = (void *) 0x0

Compared to regular didbs git cannot clone from https.

#include <iostream>
#include <cstdlib>
#include <pthread.h>

using namespace std;

#define NUM_THREADS 5

void *PrintHello(void *threadid) {
   long tid;
   tid = (long)threadid;
   cout << "Hello World! Thread ID, " << tid << endl;
   pthread_exit(NULL);
}

int main () {
   pthread_t threads[NUM_THREADS];
   int rc;
   int i;

   for( i = 0; i < NUM_THREADS; i++ ) {
      cout << "main() : creating thread, " << i << endl;
      rc = pthread_create(&threads[i], NULL, PrintHello, (void *)i);

      if (rc) {
         cout << "Error:unable to create thread," << rc << endl;
         exit(-1);
      }
   }
   pthread_exit(NULL);
}

Crashes with g++ threads.cpp -pthread -lpthread, works with g++ threads.cpp -pthread. For now, "don't do it then!" is a good enough workaround, but this probably shouldn't happen. For some reason I suspect this may have more to do with binutils than compiler.

Currently this script emits $ python3-config --ldflags -L$(echo /usr/sgug/lib32 | sed s#/usr/sgug#$(installed_prefix /usr/sgug/bin/python3-config)#) -lsocket -lnsl -lintl -ldl -lm -lm

When changed to use bash, it runs properly:

$ python3-config --ldflags -L/usr/sgug/lib32 -lsocket -lnsl -lintl -ldl -lm -lm

Already seen in bash (currently disabled) - but this also has spilled over into coreutils causing things like "sort" not to work on numeric fields.

openssh 8.1 in 0.5 has no sshd init.d file so I wrote one and offer it up for inclusion.

http://www.stellarcore.net/downloads/sgi/sshd.init

I named it sgug_sshd as SERVICE and copied the K02 and S98 files from neko_sshd. This would all have to be handled in POST INSTALL SCRIPT.

-Mike

This is changeable (in 0.0.3) inside the /usr/sgug/etc/rpm/macros file or by overridding that value with a ~/.rpmmacros file.

For 0.0.4 target the default will be defaulting to NUMPROC (the etc file will be moved into an rpm) - and anyone wanting to override that should add something to their private rpmmacros file.

Now we start to have some GUI applications that are useful, it would be nice that these appear inside the Indigo Magic toolbox with nice icons.

There was a post in the SGUG forums about setting the right flags on executables that would be the place to look about what needs to be done to the application themselves - but perhaps we can abuse the existing desktop-file-utils or whatever it's called as the place to hook into "new GUI application added, do some magic to add it to the toolbox".

This is a new feature - so I suggest we trial it in a few steps:

(1) How to set the right flags on pidgin to be able to create the icon / shortcut style thing
(2) How to hook into new applications becoming available in a centralised package
(3) How to them use the hook so that some toolbox area for SGUG has things added and removed.

Deeper investigation needed, but FWIR the ncursesw library in RSE is broken, while the ncurses lbrary non-wide seems ok.

This must be an RSE thing, as the regular and wide character libraries in DIDBS were fine - so it's something specific to the RSE build or configuration.

To be polite it would be good to do a pass double checking that there isn't any Redhat or Fedora assets or naming left in place.

Off the top of my head, there's a least the perl-Fedora-* package that probably need renaming (and what depends on it).

As per title, xterm works well enough but the scrollbars aren't showing what they should.

There is a %bcond_without trace that might help - it turns on the xterm package build "trace" functionality (it dumps files in the directory where xterm is run).

ignore

This script, found in the Python source at Python-3.8.1/Tools/scripts/pathfix.py , is referenced in the gtk2.spec:

# Use python3 shebang instead of ambiguous python pathfix.py -pn -i %{__python3} $RPM_BUILD_ROOT%{_bindir}/gtk-builder-convert

There's various things we could do here, including

• add the Tools to our python package
• add this one script into the gtk2 package as a patch
• something better

Version seems mismatched with underlying version.

Some things to revisit once things are up and stable:

/usr/sgug/etc/rpm/macros
/usr/sgug/lib/rpm/pythondeps.sh

I've tracked this down to the newer libdicl-0.1.18 version.

Installing libdicl-0.1.16 before building RPM and then afterwards re-install of libdicl-0.1.18 is the current workaround.

[sgugshell esp@OCTODAD ~]$ cat hello.cpp
    #include <iostream>
    using namespace std;
    int main()
    {
        cout << "Hello, World!\n";
        return 0;
    }
[sgugshell esp@OCTODAD ~]$ g++ -o hello hello.cpp
[sgugshell esp@OCTODAD ~]$ ./hello
Hello, World!
[sgugshell esp@OCTODAD ~]$ ldd hello
        libstdc++.so.6  =>       /usr/sgug/lib32/libstdc++.so.6
        libm.so  =>      /usr/lib32/libm.so
        libgcc_s.so.1  =>        /usr/sgug/lib32/libgcc_s.so.1
        libc.so.1  =>    /usr/lib32/libc.so.1
[sgugshell esp@OCTODAD ~]$ g++ -o hello hello.cpp -lpthread
[sgugshell esp@OCTODAD ~]$ ./hello
Segmentation fault (core dumped)
[sgugshell esp@OCTODAD ~]$ ldd hello
        libpthread.so  =>        /usr/lib32/libpthread.so
        libstdc++.so.6  =>       /usr/sgug/lib32/libstdc++.so.6
        libm.so  =>      /usr/lib32/libm.so
        libgcc_s.so.1  =>        /usr/sgug/lib32/libgcc_s.so.1
        libc.so.1  =>    /usr/lib32/libc.so.1

The relevant .so files are from the binary distribution.

As suggested by @unxmaal - this may be interesting to look into to see what/if we get any benefits from it.

http://www.sgidepot.co.uk/sgidepot/sw-fuelwithMayaAvidAlias.html
neko_glitz
glitz-0.5.6 GL based xrender replacement

https://www.freedesktop.org/wiki/Software/glitz/

A place to add notes and reproduce cases for our toolchain bug related to multi-GOT.

This python script (https://esp.iki.fi/generate3.py) was mentioned as generating things that exhibit the behaviour, I've personally not had the time to run this yet + compare against MIPSpro / older toolchains.

@onre if there's anything you feel like adding, please do!