Setting up PackMan from scratch

I am setting up a new RISC OS computer. Last time I did this, for my parents, I installed PackMan and then installed as much software as possible via PackMan so that it would help keep things up to date for them, so I was intending to go the same way with this latest machine.

The PackMan User’s Guide here on the ROOL site suggests downloading the application initially from the Alan’s RISC OS stuff site. The version available there has two sources listed in PackMan.Resources.Sources, namely:

• pkg http://packages.riscosopen.org/packages/pkg/programs-armv5
• pkg http://packages.riscosopen.org/packages/pkg/thirdparty

If I look at the containing folder on the packages.riscosopn.org site, the first of these sources does not seem to be present any more.

Looking at the PackMan help, there is a page about “Known Sources” which explains a bit more about these sources. It seems that the following are in fact synonyms:

• thirdparty
• raspberrypi-programs-armv7
• programs-armv7

The only other source there with recent changes is the one named “rool” which looks like hard disc components of RISC OS as described on the Packaged software page.

There is a “raspberrypi-programs-armv5-old” dating from 2012. That seems to be identical to http://www.riscos.info/packages/pkg/autobuilt

Is the disappearance of “programs-armv5” from the ROOL site intentional? Does it have something to do with the rebuild of riscos.info?

On another machine where the package lists from “thirdparty” and “programs-armv5” were fetched several weeks ago, I see that if I look in Packages.Available I can see the consolidated lists, and I can find, for example, FTPc in there. That gives a package URL of http://packages.riscosopen.org/packages/arm/Network/FTPc_1.56-1_arm.zip but if you go to http://packages.riscosopen.org/packages/arm/ you will find there is no Network folder there.

I’m not sure whether these two anomalies are related. I suppose I had better email ROOL via the address given on the RISC OS Packaging Guide page.

Is the disappearance of “programs-armv5” from the ROOL site intentional? Does it have something to do with the rebuild of riscos.info?

I can’t answer for ROOL, but yes it may have to do a lot with the recent problems with riscos.info.

PackMan breaks when even a single source is not working properly, which is a problem.

AFAIR, “programs-armv5” used to be a pointer to riscos.info packman repository.

if you go to http://packages.riscosopen.org/packages/arm/ you will find there is no Network folder there.

The issue seems to be that there isn’t a standardised way to create RISCPkg repositories, for instance the way I did on the riscoscommunity.org is explained here:

https://riscoscommunity.org/add-our-riscpkg-repositories-to-your-packman/

Given that I only allow HTTPS (and for good resons to protect RISC OS users), I also had to provide a “local” copy of CaCerts when riscos.info started to have problems. It would be nice if ROOL would host the certificates given that without that package PackMan is unable to use https.

HTH

I’m also experimenting with setting up my own repository. This may not be a permanent thing, but it does make it easier to test software distribution before contributing a package to the RISC OS Open repository.

I think the list of packages that you get by accessing the URL that you place in the PackMan Sources, for example, http://packages.riscosopen.org/packages/pkg/thirdparty is just the contents of all of the Control files with three fields added, namely URL, MD5Sum, and Size.

I notice that your list at https://riscoscommunity.org/packages/rpkg/arm32/released does not include the Size field. Interesting that PackMan does not care about this (assuming your list works, which I have not checked).

I notice that your list at https://riscoscommunity.org/packages/rpkg/arm32/released does not include the Size field. Interesting that PackMan does not care about this (assuming your list works, which I have not checked).

When I tested it, it didn’t care about the file size. However the MD5 matters a lot, IIRC, is used to determine if the ifle is in the local cache already, but it’s been a while since I have created mine, so I may remember wrong.

As per “assuming it works fine”, it does, I have repos for testign purposes only and they are used every day by my automation, if there are problems with them those should be reported.

And yes I push packages into the alpha quality repo and then run tests on a bunch of system “automatically” (double quotes is because I need to use a software to press buttons on PackMan, which is why I started to write my own module that is like a command line packman, it will make automated tests a lot easier).

Given that I only allow HTTPS (and for good resons to protect RISC OS users), I also had to provide a “local” copy of CaCerts when riscos.info started to have problems. It would be nice if ROOL would host the certificates given that without that package PackMan is unable to use https.

Since PackMan uses curl for fetching from the internet, and the libcurl3 recipe in the autobuilder (since 2019) uses the certificates from InetDBase:CertData that are included in the ROOL HardDisc4 archive, where does the dependency on !CaCertificates come from?

Since PackMan uses curl for fetching from the internet, and the libcurl3 recipe in the autobuilder (since 2019) uses the certificates from InetDBase:CertData that are included in the ROOL HardDisc4 archive, where does the dependency on !CaCertificates come from?

When tested on Vanilla RISC OS (which is where I test the most), it couldn’t do https and was failing. It was few releases before the one that is available now. So, it’s possible that ROOL InetDBase:CertData is outdated and certainly the lack of an auto update for this makes things very user unfriendly, hopefully it will change overtime.

The situation, AFAIR, got quite outdated that even Dave H. wrote a tool to update those certificates. So, I thought it was public knowledge at this point.

I haven’t tested if PackMan is ok with Dave’s tool, I just wish ROOL would solve this issue and distribute CertData updates for all of us, but maybe I am asking for too much.

I just wish ROOL would solve this issue and distribute CertData updates for all of us

They do – the freshest CertData is in the !Internet package which is available…on PackMan. Now obviously there’s a bootstrap paradox if the certificate authority of the site which hosts the package got revoked, but you can always sidestep PackMan and just get the ZIP file manually.

pkg http://packages.riscosopen.org/packages/pkg/programs-armv5
pkg http://packages.riscosopen.org/packages/pkg/thirdparty

If you visit the “armv5” URL listed above with a browser such as Safari or NetSurf, you get a package list from riscos.info instead of riscosopen.org (there appears to be a redirect in place – perhaps the directory listing omits any redirects). The second URL has now reappeared on the index page you linked to above, so should be OK.

However, PackMan still has problems: I think I’ve discovered some of what’s going wrong.

• As mentioned above, the two “armv5” package sources on riscosopen.org redirect to the “raspberrypi” package source on riscos.info. Normally this wouldn’t matter, but…
• The package lists on riscos.info now specify a relative URL for the package download. That is, instead of
  URL: hxxp://www.riscos.info/packages/arm/Example/Example.zip
  it is now specifying
  URL: ../arm/Example/Example.zip
• PackMan, processing what it considers to be a package list downloaded from riscosopen.org, constructs the URL as
  hxxp://packages.riscosopen.org/packages/arm/Example/Example.zip
  which obviously won’t work.

Workaround: Instead of using the ROOL “armv5” package sources, use http://www.riscos.info/packages/pkg/raspberrypi as a package source. The other ROOL package sources (raspberrypi-system, rool, thirdparty) can be left as-is.

I haven’t tested if PackMan is ok with Dave’s tool, I just wish ROOL would solve this issue and distribute CertData updates for all of us, but maybe I am asking for too much.

My approach was to give everyone the easiest possible way to get up to date CA certs directly from the prime source. No intermediary involved.

https://davehigton.me.uk/

My approach was to give everyone the easiest possible way to get up to date CA certs directly from the prime source. No intermediary involved.

Thanks Dave, I need to test if your tool works fine with PackMan, my fault, lack of time as usual.

They do – the freshest CertData is in the !Internet package which is available…on PackMan. Now obviously there’s a bootstrap paradox if the certificate authority of the site which hosts the package got revoked, but you can always sidestep PackMan and just get the ZIP file manually.

BOOM! That’s what I was hoping for and hopefully tomorrow I have enough time to test it and update my instructions on the riscoscommunity.org’s page!

As always thanks Sprow!

Thanks Stuart for that investigation. That explains a lot, and gives a nice workaround. And good to have the reminder about how to keep the certificates up to date.