The SGUG RPM Software Environment

hammy

Member
Jun 1, 2019
86
46
18
UK
Release 0.0.3 alpha of the sgug-rse project on github is now out - and should (modulo bugs) be feature equivalent with the packages and features previously provided by didbs.

sgug-rse is interesting - in that this opens up a common repository and submission place for extra packages and ports - from you!

Pull requests and new ports are most definitely welcomed and encouraged.

It's currently for developers/early adopters - with focus and usage we can discover the sharp corners and get things a little smoother.

I recommend a "fresh" install (remove previous sgug-rse) for sanity.

There is an obvious known issue - if you're having issues with `sort` or other tools, `LC_ALL=C` is a work around. Please do file any bugs you see and we'll try and get this stable enough for everyone.

Get it here!
 

stormy

New member
Jun 23, 2019
20
5
3
Hi Hammy, I'm new to porting and with the help of Jupo only just got didbs installed and working. Would you suggest I stick playing around and learning with the didbs environment for now and waiting until sgug becomes more mature?
 

hammy

Member
Jun 1, 2019
86
46
18
UK
Hey Stormy,

For the moment the rpm bits are alpha and are probably only of interest to early adopters / people who don't mind stuff being a bit broken.

I'm working my towards 0.0.4beta - which should be in a much better place with various improvements under the hood to make life nicer.

Stick with didbs for now, get your feet wet using those tools and we see when 0.0.4 arrives.
 

hammy

Member
Jun 1, 2019
86
46
18
UK
On the road to 0.0.4beta, some stats for funsies from the "rebuild the world #1":

  • 128 packages now in the "working set" of sgug
  • 691M of SRPMs generated
  • 506M of RPMs generated (115 NOARCH .rpms, 348 MIPS .rpms)
  • Full rebuild on dual 600 octane2 -> ~26 hours
  • Slowest to build -> boost C++ library at a whopping 4.X hours
Some more tweaks to fix a couple of outstanding issues and another full rebuild and we're on track for 0.0.4beta in a week or so.
 
  • Like
Reactions: Elf

hammy

Member
Jun 1, 2019
86
46
18
UK
Is there a nice script to build the world of RPMs? So we can have MIPS4?

-andy
Kinda .-)

Since the packages are in flux, any script is out of date as soon as a new package is added or something gets renamed. Plus there's an ongoing bug where rpm requires libdicl 0.1.16 during build - while other packages like libtasn1 and p11kit require version 0.1.17 during build. All will _run_ against 0.1.17, these are just build-time hard needs.

But to the chase - I've built a tool that can spit out the list of which .spec files correspond to the rpms you have installed - which can then be massaged into a build script - but it's still raw, and needs tweaking for the above.

I did it like this so that I could sanity check I'm rebuilding everything that's installed (and not just missing something).

Once that tool gets a little more mature I'll stick it (and it's sister tool - "compute minimal packages") in a "sgug-rse-tools" repository.

I've not looked into what it would take to compile everything mips4 until now - so no idea if that would easily work.
 

hammy

Member
Jun 1, 2019
86
46
18
UK
sgug-rse 0.0.4beta here with some notes: https://github.com/sgidevnet/sgug-rse/releases/tag/v0.0.4beta

If you want to install all the RPMs there - launch the sgugshell and extract the "RPMs" tarball in the right place then:

Code:
cd ~/rpmbuild/RPMS
sudo rpm --reinstall -ivh noarch/*.rpm mips/*.rpm
@stormy @praetor - This should be in a good enough state that most sharp corners have been taken off it if you want to dive into RPMs on IRIX!

Known Issues:

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

@massiverobot - the world rebuilder script I used for this is here: https://gist.github.com/danielhams/ccf20403842a7e3a8e0b751a4254eddd

It still needs a manual dance to build libdicl-0.16, downgrade to that, rebuild rpm, build libdicl-0.1.17, upgrade to that, upgrade rpm. That isn't automated for the moment.
 

hammy

Member
Jun 1, 2019
86
46
18
UK
Retirement of WIP (sgug-rse-wip.git in github)

The Why

Previously we've used a second github repository as a "free for all" in terms of what may be checked in/versioned. This has served us nicely while we got started - and we've had lots of changes and new things become available via this mechanism.

This has presented new challenges about our workflow that the sgug team have discussed:
  1. New packages like the libX11 client libraries come online in sgu-rse-wip
  2. This breaks quite a few of the built packages in sgug-rse like emacs, vim, ddd and a few others
  3. So the changes to the wip packages need to be in sync with and versioned against changes to packages in the main repository
We think we have a solution using a single repo that doesn't destroy our agility.

The Change
  1. We'll have the existing "master" branch in sgug-rse like today, changes only via pull request and approval within the team
  2. We'll have a branch related to the "up and coming" release - currently that would be "release0.0.5beta" - and this branch too requires a pull request and approval within the team
  3. There will be a "wip" branch equivalent to the existing sgug-rse-wip repository - if you are a member of sgug team you can push directly - pull requests from outside (the explicit team) are more than welcome and have equal standing
  • wip is "HEAD" / "DEVELOPMENT"
  • releaseX.X.X is the "RELEASE CANDIDATE" / "RELEASED VERSION"
  • master is "MOST RECENT STABLE"

In terms of what this changes - this will allow us to be able to (in wip) stage changes that affect core sgug-rse packages against the dependencies either on or from things that are "work in progress"

The Process
  1. Everyone commits and pushes ongoing work to sgug-rse-wip
  2. We freeze the sgug-rse-wip repository
  3. The new branch "release0.0.5beta" contains the changes exclusively for the 0.0.5beta release, and can have updates/big fixes added to it until we are happy
  4. The frozen package ".spec" file from sgug-rse-wip are copied over into a new branch "wip" (clone from release0.0.5beta) of the main sgug-rse repository
So WIP continues as-is - but as a branch inside the main sgug-rse repository.

We have a branch for the ongoing next release - until the time where we feel it's ready for a general release.

At "release" time, the specific release branch is merge to master, and the next release branch is created.

It's a bit of organisational "faff" - but we avoid this issue of trying to check multiple repositories for changes.

Feedback welcomed - unless there are major blocking objections, I'd like to get this migration/swapover done at next opportunity, and get 0.0.5beta out the door (then our maintainers feel the pain of updating sooner rather than later).

Note For Clarity: This doesn't mean that "0.0.5release" will include new libX11 client libraries or the updated and versioned python bits, these remain "works in progress" for now, but there are already significant changes in 0.0.5 (the release notes will detail those updates) that it shouldn't be delayed any further.
 
  • Like
Reactions: Elf

HAL

Administrator
Oct 22, 2019
6
2
3
Your suggestion reflects what we agreed to previously, looking forward to fill up the new wip with SPECS and SOURCES :)
 

Elf

Storybook
Feb 4, 2019
253
57
28
Makes sense to me ;)

One suggestion I have would be, if people are trying things out, try it in a separate feature branch (branched off of WIP) and at least get it to something of a working state before merging it into the WIP branch. That way outstanding work that isn't finished yet doesn't "break the build" for all other WIP contributors.
 

hammy

Member
Jun 1, 2019
86
46
18
UK
One suggestion I have would be, if people are trying things out, try it in a separate feature branch (branched off of WIP) and at least get it to something of a working state before merging it into the WIP branch. That way outstanding work that isn't finished yet doesn't "break the build" for all other WIP contributors.
Your suggestion above is good - but isn't that in effect a "wip" branch for "wip" .-)

I'm still not sure what makes sense in terms of what we do about "this is partially broken" packages - since there's various different levels of broken. (The below doesn't even take into account package self-test failures, either).
  • Package builds fine, installs fine, runtime issue or bad config
  • Package builds fine, installs but issues with file placement and/or pre/post triggers
  • Package kinda builds, produces some stuff you can't install (e.g. rpm#1 install OK, rpm#2 cannot install)
  • Package builds, but it's all kinds of "not in line with fc31" (e.g. current glib)
  • Package doesn't build or is properly broken (e.g. jack1)
For reference my current "build the world" tool works like this:
  1. Look at all the `.spec` files inside your `~/rpmbuild/SPECS` directory
  2. Parse them with the rpmlibraries, work out which _output_ rpms they produce
  3. Look to see if there is an _installed_ rpm on the current system that matches -> if so, add the related `.spec` to the list of "should be rebuilt"
So the flaw with this current approach is that it has no idea of "brokeness" - or "only build this subset of things on the system"

The whole build/versioning/archives/artefacts needs an overhaul, that's clear. It's not currently clear to me what a "nice" target solution would look like.
 
  • Like
Reactions: Northsky

Elf

Storybook
Feb 4, 2019
253
57
28
Yep, a work-in-progress that is too -in-progress for WIP :p

Up to the individual of course, but my thought is: if you are making changes to other packages to rely on your package, and your package is not fully working yet, containing that in a feature branch can be a good thing until you are ready to subject others to it!

I am going to ponder your question about seeing what needs to be rebuilt. It seems like a bit of a dependency graph problem with some configuration?
 

hammy

Member
Jun 1, 2019
86
46
18
UK
I am going to ponder your question about seeing what needs to be rebuilt. It seems like a bit of a dependency graph problem with some configuration?
It's a _wee_ bit more complicated than that unfortunately. Have you had a chance to _use_ `rpmbuild` and checking stuff in/out from github?

Probably the most notable issue (I think) - is that you _don't know_ what dependencies a particular package will have (or which packages will start to depend on it):

  1. The package must be build so that the "hidden" dependencies can be computed (shared library links, dependencies from scripts/perl etc)
  2. Once a package is installed, rebuilding other packages may now start to have "hidden" dependencies on the new package
In effect, this makes dependency computation from the `.spec` files alone impossible (or at best an approximation).

Edit: The above issues are why every "build the world" for a release has to be done a minimum of two times -> first time to allow packages to pick up and configure themselves against things already installed, then a second time so _other_ packages can pick up any changes that may occur inside the first round.
 
Last edited:

massiverobot

irix detailer
Feb 8, 2019
73
47
18
Philly
twitter.com
Beta 5 works great on '32bit' O2s, and I'm sure will work as well on the Indy.. (I don't have Indy to test.) Thanks Hammy for this next excellent release.

I guess I should get my Challenge S up and working so I can see what this acts like on the Indy platform.

Anyone of you out there w/ an O2 or Indy- this is a super easy install, and distCC will make your compliation happen fast (using your other modern PC).
 
  • Like
Reactions: hammy

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu