RISC OS is open for business!

There will be a longer press release to the RISC OS news sources in the next 24 hours.

Which doesn’t really matter because both Icon Bar and I published something based on the PDF – but I saw that also went to csa.announce, so I didn’t bother reading through the other thread on .misc to bring the subject up.

However, looking this morning… still no discussion (or even a solitary comment) about it! So I followed-up the .announce post itself into .misc with an off the cuff remark about how packed the ROSDev talk will be.

One of the ideas ROD brought up at a recent meeting with ROOL was the idea of a (subsidised?) developer meet/conference session. Such a workshop would make an excellent part of that, I suspect.

We’ve previously run developer summits for FreeBSD folks in Cambridge. Could possibly organise something similar – I’d have to check, but I imagine it should be fairly low cost. Dates would be constrained by building availability (not sure how far in advance it would need booking).

(I suggested this a couple of years ago to ROOL, but info@riscosopen seems to be a bit of a black hole)

One thought that occurred to me was that people tend to congregate anyway for RISC OS shows. Perhaps the day after one of those might be a good developer-meet day? (eg. after Wakefield or Bristol [new venue] next year)?

This is assuming there’s significant interest.

:-)

CVS access rights have now been suspended while the licence to the source code is updated.
This commit should have failed. Oops…

(my emphasis)

I can get a venue for free on a Sunday

RISC OS is unfortunately in a very weak position to benefit from typical Open Source-big business-sponsor-/partnership (either monetary or man-power)

Some smaller Open Source OS benefit from the Google Summer of Code.

Hum, and for DDE, I don’t think ROOL expect to get a lot of money from it. So perhaps that the community could buy the right to get it for free forever. An idea for a super bounty?

Sounds like a thin-client to help with source submission and continuous integration would be useful.

I agree.

I have found myself using GitHub a little (for work) and the ease of:

• browsing code
• searching code
• viewing diffs for PRs
• managing PRs
• discussion of bugs/PRs
  is very good.

It is fairly simple to upload files with a browser. You don’t have to mess on with git itself.

How can we make GitHub usable from RISC OS? Do we need to polish up a git port?

There’s a whole CI/CD world that I’ve been gradually pushing RISC OS pieces towards:

• Version control: CVS is a pain. riscos.info uses SVN which is marginally less annoying, but still painful. git workflows are much more amenable to non-core contributors. The standard git client however is moderately heavyweight. I did a port in the riscos.info autobuilder but it’s not usable through too much being broken. However, in the same way that TLS is using mbedtls rather than the canonical OpenSSL, there is a libgit2 which is a simpler implementation, and a client based on that might be easier to handle. A nice project for someone would be to see if a client can be made or ported – for example the Amiga folks have SimpleGit

Github is good as a general service for interacting with code, and the nature of git means there isn’t much risk of Microsoft taking their ball home (at least for open source projects). Moving to git would be a big pain, however – I’ve tried moving GCCSDK and it’s not straightforward.

• Continuous integration: the ROOL build server is a heroic means of running RISC OS native builds on a remote server, but realistically for this you need a cross-compiler. Builds go a lot faster when you can throw 32 cores at them. riscos.info has a Jenkins CI system that cross compiles using GCCSDK. It turns out some of the plumbing isn’t compatible with recent Linux kernels, which the new server is running, and hence ci.riscos.info is currently unable to build anything. I want to push this towards building Docker containers of the tools, which would solve the problems Jenkins is having, but would also distribute compiler builds. So when you want to compile a RISC OS program you simply ‘docker pull riscos-gcc’ and you have a build environment. (An elephant here is that nobody is currently maintaining RISC OS GCC)

• Testing: currently, RISC OS has no tests. When a build happens, it’s thrown up on the website and presumed good. It would be good to at least boot it somewhere and check that it still works. Further, it would be good to check things still work in the same way as last time – this is important when verifying the pull requests that people send. Recent work with Raspberry Pis (particularly USB boot and the Cluster Hat ) make it easier to automate tests like this. Further down the line, a framework that RISC OS pieces can plug their tests into would be handy.

This is a lot of work, and is broadly orthogonal to the kinds of OS-level work that most of the bounties are focusing on. I would suggest that moving away from CVS is probably the first step, as it then enables a lot of other things.

I’m curious about the ROOL build server — is there any public info about this?

It seems that the two most straightforward ways to get a personal RISC OS build environment set up are to run it native on a Pi, or to run under emulation using RPCEmu on Windows. (I first started trying to set one up on a Mac, but the server hosting the RPCEmu 0.9.0 port is down right now.) Does this sound correct?

I’m curious about the ROOL build server — is there any public info about this?

I believe that it’s a machine with RPCEmu. Every night a timer triggers a task that grabs the current source out of CVS and drops it into the HostFS directory. It then launches RPCEmu, which has an Obey that runs on startup and builds the OS and drops the resulting files into HostFS. These files then get grabbed and uploaded to the site.

I think that’s the gist of it, anyway :)

Hi. The autobuilder is indeed a cloud server (Linux) running a headless version of RPCemu. Every night, it uses rsync to update its local mirror of the public CVS repository, then it runs (in sequence) all of the builds that we have scheduled (maybe ten or so). It has some short-cuts to spot when nothing significant has changed in CVS so no builds are run. It ain’t particularly sophisticated and, as people here have observed, it doesn’t really have any test automation (which is easier said than done given we don’t have emulators of all of the hardware targets for RISC OS).

It looks like all the recent publicity has upped the spam rate on this forum. I suppose the upside is that it means we are being noticed.

I might be the last one to comment on this thread as well (wanted to wait until I had time to watch the London show talks – thanks Leo).

I’m cautiously optimistic about this news.

This is all about removing barriers to adoption and contribution for RISC OS. Any potential outcomes around fragmentation or closed source forks would, to be honest, be a nice problem to have, IMO! Anyway, I personally see those as the extremes – there are a lot of significantly more positive outcomes that we should be looking forward to.

I think Steve makes a great point here. At this stage anything that encourages wider adoption of RISC OS and interest is probably a good thing for its long term future. If some very different derivative winds up flourishing the most in a decade or two, it’s not like the old versions of the OS will cease to exist. So, I’m going to allow myself to get a little excited about this and say well done to the efforts of those that are bringing these changes about!

It has some short-cuts to spot when nothing significant has changed in CVS so no builds are run.

I’m curious about the current operational status as I see that the latest build of ROMs is 2018-10-01 (v5.27) and the latest source bundle is 2018-10-01 (v5.27) with no listed change in CVS.

I presume the CVS “latest updates” is correct in showing nothing for some days and that the v5.27 build/bundle is identical to the last of the v5.25 build/source bundles.

The announcement at the top of the thread does very clearly say “RISC OS has been up-versioned to 5.26 to signify the first official stable release of RISC OS under the Apache 2.0 license. This is actually functionally identical to 5.24” and that v5.27 is simply v5.25 carried forward with the new licence.

The announcement at the top of the thread does very clearly say “RISC OS has been up-versioned to 5.26 to signify the first official stable release of RISC OS under the Apache 2.0 license. This is actually functionally identical to 5.24” and that v5.27 is simply v5.25 carried forward with the new licence.

Indeed, however either the pages are incorrectly showing v5.24 as the stable or the available download isn’t v5.26 and the v5.27 build has occurred without a triggering change in the CVS content being recorded on the CVS revisions page. I seem to recall the statement in a forum announcement that all the licence info in the CVS had changed…

Interview with RISC OS Developments regarding the Open Sourcing of RISC OS.

https://www.techradar.com/news/arms-original-operating-system-goes-open-source

the available download isn’t v5.26 … I seem to recall the statement in a forum announcement that all the licence info in the CVS had changed…

See this post for an explanation.

So when you want to compile a RISC OS program you simply ‘docker pull riscos-gcc’ and you have a build environment. (An elephant here is that nobody is currently maintaining RISC OS GCC)

I recently threw together a docker image with the crosscompiler built for amd64 linux systems (https://hub.docker.com/r/akuneko/riscos-gccsdk/). I just haven’t had the time to actually test it since I pushed the image – nothing I’ve seen yet suggests it doesn’t work, but I haven’t been looking too deeply yet.

I’ll likely give it a good workout in the next few months (patching packages and tools to run reliably on Pi3s since that’s what I’m using more these days rather than the old Pi1).

Here are some other outlets that our news has reached:

• Tech Radar Pro
• Its FOSS
• Computer Weekly
• Linuxfr.org

I recently threw together a docker image with the crosscompiler built for amd64 linux systems (https://hub.docker.com/r/akuneko/riscos-gccsdk/). I just haven’t had the time to actually test it since I pushed the image – nothing I’ve seen yet suggests it doesn’t work, but I haven’t been looking too deeply yet.

Looks nice – I’ll use that when I next get some time to redo ci.riscos.info. I’d have one comment though – it appears you’ve made the env/ tree be a subdirectory of the cross/ tree. The latter is the crosscompiler, while the former is the local environment (eg RISC OS libraries and header files put there by ‘make install’). A likely use case is someone wants to mount (some of) the env/ from their build machine, while retaining the cross/ from the crosscompiler container (which will get replaced with each newer version). I know you can do that with docker, but it might make sense to keep them separate, ie /opt/gccsdk/env and /opt/gccsdk/cross. It is quite a common use case that someone will want to build with a known clean environment – eg Jenkins wants it every time.

(we could take this to a separate thread to prevent it getting mixed up with other postings here)

I’d have one comment though – it appears you’ve made the env/ tree be a subdirectory of the cross/ tree. The latter is the crosscompiler, while the former is the local environment (eg RISC OS libraries and header files put there by ‘make install’). A likely use case is someone wants to mount (some of) the env/ from their build machine, while retaining the cross/ from the crosscompiler container (which will get replaced with each newer version). I know you can do that with docker, but it might make sense to keep them separate, ie /opt/gccsdk/env and /opt/gccsdk/cross. It is quite a common use case that someone will want to build with a known clean environment – eg Jenkins wants it every time.

Sorry for the long delay, but I’m not entirely sure what you’re getting at.

If you want to replace part of the image, then the easiest way is to actually spin off a new image using this one as the reference, and then just manipulating it how you’d like.

You don’t really export the tools from the image either – they’re used in place, and you export the artefacts.

Similarly, with clean environments, you simply toss the entire runtime container and build a new one using the same image. These aren’t VMs. the runtime environment is not meant to be retained – it’s intended to be thrown out and a new one re-spun, and the container runtimes are optimised for this sort of use-case.

Anyway, despite all, that, and the fact it’s a pretty easy/trivial change, I’ve repathed the crosscompiler in my build chain and a new image will go up shortly with that change.