11/10/22 Pi ROM won't mount desktop

There was a new fix created yesterday in Git, but it is waiting approval to merge into the ROMs.

There was a new fix created yesterday in Git, but it is waiting approval to merge into the ROMs.

Regrettably making today’s image unuseable! Perhaps only for some?

[What is stopping people from submitting Merge Requests to ROOL’s GitLab?]

RISC OS client that is actually capable of doing this? (I don’t know the current state because I don’t remember hearing any more about it, but last time I checked it couldn’t actually do the full set of required actions.)

Now that’s a fair comment, and is the principal reason why USBJoystick isn’t sitting in a Git repo somewhere. I cannot be chewed farting about with another machine. I have a very small Linux WiFi/Ethernet router (which I only have because RISC OS doesn’t support WiFi) but it’s not really something I can go installing lots of software on.

The screenshots showing the bounty progress look really good. Can’t wait for that.

Also that git is absolutely incomprehensible, and I’ve not yet found a tutorial that simply shows check out, modify, check back in. And the names used for git operations are different from all other source control systems.

I know what you mean here too. We’ve migrated from TFSVC to Git at work, and the main reason for doing so appears to be ‘because everyone else is’. It might sound a bit feeble, but it actually makes sense: most developers are familiar with it, so it actually reduces barriers. I think the same would pan-out for any developer coming to RISC OS for the first time and wanting to contribute.

I think historically, most RISC OS developers have taken a dim view of source control and/or collaboration. The best you tend to get is someone sticking up a zip archive which, if you’re lucky, might build. We all need to improve on this to get those barriers to entry removed.

As ever, the StarDot forum is a goldmine. Git has recently been discussed: https://stardot.org.uk/forums/viewtopic.php?f=41&t=25151

It might sound a bit feeble, but it actually makes sense: most developers are familiar with it, so it actually reduces barriers. I think the same would pan-out for any developer coming to RISC OS for the first time and wanting to contribute.

It’s not feeble at all: people use Git, and so know how it works. In some ways, it’s probably another facet of the RISC OS world not realising that everyone else has moved on.

One fundamental reason that people have moved on is that in amongst the spiky interface, Git was clearly written on the basis that other VCSs had problems which needed to be fixed. Its better handling of branching and merging is a big one, but even simple things like being able to fix your mistakes after committing is invaluable.

I’ve been lucky, in that I started with Git in a work context on Windows, where there are good GUIs for it. I use TortoiseGit, having used TortoiseSVN with Subversion, which significantly lowered the entry barrier and learning curve. When I came to use it from a terminal on Linux for non-work purposes, I knew what I was trying to do, and “just” needed to find out what commands Tortoise was using behind the scenes. These days, I use Tortoise, the terminal, and Visual Studio Code’s client interchangeably as required.

The key thing for this discussion is that having resisted the move from Subversion to Git for many years because “Git was obscure and hard to use”, there’s no way that I’d go back now. I’m aware of the evangelism of new converts, but when I do still use Subversion (for things like WinEd, and a few private projects in my local SVN repo) I really notice its clunkiness.

Now that’s a fair comment, and is the principal reason why USBJoystick isn’t sitting in a Git repo somewhere. I cannot be chewed farting about with another machine. I have a very small Linux WiFi/Ethernet router (which I only have because RISC OS doesn’t support WiFi) but it’s not really something I can go installing lots of software on.

That will be sufficient, you don’t need to install a lot of software.

1. Install git on Linux if it isn’t already
2. Set up a Samba or NFS share so RISC OS can write to a folder on the Linux box
3. Create a git repo in that directory, setting upstream to GitLab or where ever
4. Copy the files from RISC OS to Linux
5. Get a shell on the Linux box (even !Nettle from on RISC OS will do) to add, commit, push, etc

1. Install git on Linux if it isn’t already
2. Set up a Samba or NFS share so RISC OS can write to a folder on the linux box
3. Create a git repo in that directory, setting upstream to gitlab or where ever
4. Copy the files from RISC OS to Linux
5. Get a shell on the Linux box (even !Nettle from on RISC OS will do) to add, commit, push, etc

That tells us everything except what we need. We can all set up the infrastructure to use git. (In my case, I would set up the share on NAS, accessible to both Linux and RISC OS.)

What we need is how to use git for the simple operations. Just tell us how to “check stuff out” of git and how to “check our modified stuff back in”.

How about moving this “discussion” to a topic title which has some connection and will be searchable. That is, if anything useful comes out of it.

Just tell us how to “check stuff out” of git and how to “check our modified stuff back in”.

Where? The RISC OS source tree? If so, we already have that as part of the developer documentation on this site.

ETA: Processes will vary from place to place, as a lot of the things to do with handling the ROOL sources are GitLab and not Git. The same is true of projects hosted on GitHub, or Sourceforge.

For a general introduction to Git, there are worse places to start than The Git Book.

Back to the main topic.. Rob. Thanks for creating the Merge request to fix this issue. Logging into the ROOL Git I can see the corrections. Perhaps you can push the ‘approval’ process to return this module to a functional state?
Thanks
JB

On the Git topic. Whilst there is a RiscOS git that does much, it cannot yet, AFAIK, handle the submodules as used in the RiscOS source tree.. The approach I use is to have a linux machine in the background – separate from my NAS drives – and I telnet in to that to do the relevant git stuff. FWIW as I develop HALs etc I have my own gitlab setup.. more or less an analog of ROOL’s. Yes there are a few rather verbose git commands but it is easy (!) to produce scripts, CF obey files, that sort this all out. If anyone really wants I can supply copies of these to seed your thoughts.
JB

What testing was actually done for this commit prior to the merge please?

It’s worth, perhaps, mentioning that this is part of the point of the nightly builds. I’m sure some testing was done, but clearly it didn’t catch something. So it’s our job, those of us who choose to use the nightlies instead of the stable releases, to shake out bugs, as our systems will be varied and plentiful – much more variation than a developer has access to. It’s kind of the point of these releases.

Rick. Comments accepted, and generally agreed. BUT… since this issue breaks most roms it rather suggests it wasn’t put in a dev rom AND booted prior to the merge. That is why I asked…. (I thought the ‘policing’ of merge requests would normally prevent this happening)

It’s also worth pointing out that the broken version of BootCommands is included in the PlingSystem archive, which doesn’t get tagged as part of stable releases. As a result, this can break older machines as well (just with different error messages).

Would it be possible to start doing this in the future? The current situation where the only version available could break at any time isn’t ideal.

On the Git topic. Whilst there is a RiscOS git that does much, it cannot yet, AFAIK, handle the submodules as used in the RiscOS source tree.. The approach I use is to have a linux machine in the background

Does anyone else find it ironic that a change (switch from CVS to Git) was made to make the source amendment process more accessible to various developers seems to have had the exact opposite effect?

Does anyone else find it ironic that a change (switch from CVS to Git) was made to make the source amendment process more accessible to various developers seems to have had the exact opposite effect?

It would be ironic if it was true.

The real numbers of contributors now doing it via Git is a lot higher than they ever were with CVS. Because of the nature of CVS, only very few people had commit rights, so it was mainly “contribute via diff/patch”. Which can still be done today.

CVS does not have an easy way to support a “pull-request-like workflow”, so for collaboration projects it is a real headache. And it is a security headache even if you use an ssh tunnel (which was badly supported on RISC OS anyway). So Git was really an unavoidable move. And amongst the competitors, Git is certainly the first choice.

There was a new fix created yesterday in Git, but it is waiting approval to merge into the ROMs.

And so we go on with unuseable ROM images.

Probably because of all the “noise” generated by those, some of whom complain unceasingly about noise on the forum, hi-jacking this thread to talk about Git.

As a consequence, no-one in control notices that the development ROMs are no longer serving their purpose because many of us can’t use them.

At least I’ve sorted out my reversion script now!

Perhaps pointing everyone at the current nightly build to pick up recent developments as their first port-of-call is not such a good idea! Would it be sensible to promote over this a development build that was in fact the nightly build from seven days before, and the true nightly labelled with here-be-dragons. Prospective users could scan the forums for any issues in advance of installing as I’m sure there would still be takers for the bleeding edge build.

I thought that the nightly build is dragon land. Isn’t the idea that those without nightly armour should stick to 5.28? I named my shiny armour ‘Backup’.

More people may have been seduced into the land of the dragon by the news item asking for more testers!

The point is that the testers are there to point out discrepancies.

This has been done, and yet new images keep appearing with the original fault despite a corrected ROM having been made privately available.

I (and others) are unable to test the changed features in releases after 11th Oct. There seems little point in modifying the faulty image further and releasing it for testing.

It is my choice to test new releases, but the current situation is absurd, rather like the current political situation.

It can only be helpful that I continue to check the current image, and report on its brokenness.

That’s what the test image is for. And what this topic/thread is for!

It is what it is, we are but few and ROOL is fewer still. If an extra layer of safety is required then that may be down to us to implement.

Fortunately show stopping dragons are very rare and the system has worked in this case in that the dragon has been observed and reported here, so we all can know, and duck. Beta users do have to be capable of backing out of issues arising.

The fix is ready and waiting.

That said issuing a series of duff builds is not beneficial. Developers read this noisy forum but does ROOL, who wield git’s dragon slaying merge mallet.

Probably because of all the “noise” generated by those

This is, of course, assuming that “those in charge” habitually read these fora…

At least I’ve sorted out my reversion script now!

If you’re right the nightlies, you must have an easy way of reverting.

Would it be sensible to promote over this a development build that was in fact the nightly build from seven days before

It would make sense to have rollback or checkpoint versions in addition to the bleeding edge… but these will obviously complicate the site logic (pointing at the right things) and take space on the host.

but the current situation is absurd, rather like the current political situation.

No, John. There’s simply no comparison between trashing a G7 country/economy on purpose and…. this relatively trivial situation.

who wield git’s dragon slaying merge mallet.

I’ll refer you to the previous XKCD. Adding stuff? Doable.
Reverting an edit? Oh God/Cthulhu/Etc…

;)

If you’re right the nightlies, you must have an easy way of reverting.

Pondering: Is it feasible to have an initial load that boots one of two images depending on whether a specific key on the keyboard is pressed at startup?
I know one or two people have dual boot systems that look for a gpio pin held in a specific state for a similar purpose.

This has been done, and yet new images keep appearing with the original fault despite a corrected ROM having been made privately available.

Because the fix has to be merged into the main codebase. That may not be a five minute job if other updates are pending. And even if it is, the people who do it may have better things to do with their time.

As a consequence, no-one in control notices that the development ROMs are no longer serving their purpose because many of us can’t use them.

I shouldn’t worry: I’m sure that the presence of a merge request in GitLab will have notified them far more effectively than a thread on the forum.

Pondering: Is it feasible to have an initial load that boots one of two images depending on whether a specific key on the keyboard is pressed at startup?

That may be platform-specific. I’m pretty sure you can’t do it on the Pi (otherwise people wouldn’t be messing around with GPIO pins in the first place) but it’s possible that bootloaders on other platforms may offer this functionality.

One hardware issue: Several keyboards run a power-on self-test to check for stuck keys. Such keyboards could misinterpret a key deliberately being held down at boot-up time as a stuck key and would not report that it is being pressed.