Packman setting sysvars incorrectly?

I’ve just encountered an issue where installing a package (hmail) has set up the wrong value for a system variable. Double-clicking on the app then sets it correctly. So immediately after switchon, if I type

*show Alias$hmail

Alias$hmail : Run SDFS::RISCOSPi.$.Apps.Mail.!hmail.hmail %%*0

Trying to call hmail from the command line fails.

If I double-click on !hmail and then look at the variable I get

Alias$hmail : Run SDFS::RISCOSPi.$.Apps.Mail.!hmail.hmail %*0

Calling hmail from the command line now works!

Looking inside the !Run file I see:

Set alias$hmail Run <hmail$Dir>.hmail %%*0

If I use Reporter to see what command is being run, and type

*hmail --server test

Run SDFS::RISCOSPi.$.Apps.Mail.!hmail.hmail %*0--server test

and in the second instance, the correct:

Run SDFS::RISCOSPi.$.Apps.Mail.!hmail.hmail --server test

What’s going on here? Am I missing something? What am I doing wrong?

Has the application got a !Boot file? If so, the mistake may be in there.

The !Boot file also says:

Set alias$hmail Run <hmail$Dir>.hmail %%*0

Just realised therefore that just seeing !hmail is enough to set the Alias correctly. Still don’t understand why Packman appears to set it wrongly.

SysVars was deprecated in RiscPkg format 0.40 – I think that was 2014 or thereabouts; hmail is from 2007. Just a LookAt would suffice at boot in the modern world.

SysVars was deprecated in RiscPkg format 0.40 – I think that was 2014 or thereabouts; hmail is from 2007. Just a LookAt would suffice at boot in the modern world.

hmail claims copyright 2005. Does this mean that I have to go back to the original author and ask them to repackage it in a newer format so it will install correctly?

It’s a trivial change but I don’t know where this one is being downloaded from to be served up to PackMan by the ROOL servers.

Given that it was last compiled in 2007 I’d expect it might have SWP issues etc.

It’s a trivial change but I don’t know where this one is being downloaded from to be served up to PackMan by the ROOL servers.

It claims to be coming from http://www.riscpkg.org/arm/hmail/hmail_1.01

Given that it was last compiled in 2007 I’d expect it might have SWP issues etc.

It comes with source which I’ve managed to recompile so it does work now!

To be honest, I was only fiddling about with something, it’s turned into rather more effort than I intended, but now I’m here I might as well try and get it so someone else can actually make use of it!

Just realised therefore that just seeing !hmail is enough to set the Alias correctly. Still don’t understand why Packman appears to set it wrongly.

The problem here (other than it using a deprecated mechanism) is that hmail’s SysVars alias=...hmail file shouldn’t have a trailing %%*0 for arguments (as if it were being set from an Obey file, to avoid substitution), but %*0 (as if it were being set from the command line)

The SharedLibs package is still using SysVars, but correctly, with the trailing %*0 for arguments.

It claims to be coming from http://www.riscpkg.org/arm/hmail/hmail_1.01

The riscpkg.org packages are essentially legacy – the owner of that site hasn’t been maintaining it for a long time. When I set up packages.riscosopen.org I wrote a script to filter the feed from riscpkg.org and drop any packages that were problematic, which made a new ‘safe’ package list for the ROOL armv5 feed. ROOL took over running that site and so I’m not sure if that script is still running, but if you have the riscpkg.org package list then you’re getting the ‘unfiltered’ packages.

Andrew, if you wanted to update the package and bump the version number in the Control file I’m happy to add it to the riscos.info repo, which should be picked up by people who have that in their feed.

The problem here (other than it using a deprecated mechanism) is that hmail’s SysVars alias=…hmail file shouldn’t have a trailing %%*0 for arguments (as if it were being set from an Obey file, to avoid substitution), but %*0 (as if it were being set from the command line)

So does this mean that the fault lies in the package being created wrongly by the author rather than in Packman itself?

The riscpkg.org packages are essentially legacy – the owner of that site hasn’t been maintaining it for a long time. When I set up packages.riscosopen.org I wrote a script to filter the feed from riscpkg.org and drop any packages that were problematic, which made a new ‘safe’ package list for the ROOL armv5 feed. ROOL took over running that site and so I’m not sure if that script is still running, but if you have the riscpkg.org package list then you’re getting the ‘unfiltered’ packages.

The only feeds I have ticked in Packman are:

http://packages.riscosopen.org/packages/pkg/programs-armv5
http://packages.riscosopen.org/packages/pkg/programs-armv7
http://www.jaspp.org.uk/packages/release

I don’t remember adding or removing any from it, so I guess these are the default settings, but I could be wrong.

Andrew, if you wanted to update the package and bump the version number in the Control file I’m happy to add it to the riscos.info repo, which should be picked up by people who have that in their feed.

It’s not my software to say what happens to it, I’ll see if I can contact the author to see if he will modify it.

So does this mean that the fault lies in the package being created wrongly by the author rather than in Packman itself?

Yes, as this mechanism is being used successfully by at least one other package.

I have vague memories from a few years back about another package with a similar fault, but it escapes me!