PackMan package manager 0.9.2 beta released

PackMan version 0.9.2 beta is now available.

The main reason for this release is to allow PackMan to filter the lists
of packages to show only those that should be able to run in the environment
PackMan is running in.

This will need package authors to update their packages with this information
so currently this means you will get a warning triangle by the package name
to indicate nothing is specified about the environment for most packages.

It also allows package authors to release multiple versions of a package of
the same version targetted at different environments. e.g. a standard version
and a version that runs better with VFP hardware on the machine.

Package Maintainers, please add the new Enviroment field when you create a
new package or update an existing package.

Also in this version:

- Packages can include a Homepage field to give a link to more information
about the packaged software and PackMan will show this link with a
button to launch it in your (AcornURL compatible) web browser.
- Empty directories can now be included in packages.
- Help text fixes contributed by a PackMan user.

If you already have a previous version of !PackMan or !RiscPkg
installed you can install it or upgrade it from either of
these programs.

The latest versions of PackMan are now distributed via the ROOL packaging
sites. RiscPkg and the older versions of PackMan may not have these
sources in the list of sources. If this version of PackMan doesn’t appear
as an update in your browser you probably need to add the following url
to the PackMan sources.
http://packages.riscosopen.org/packages/pkg/programs-armv5

Otherwise go to https://sites.google.com/site/alansriscosstuff/packman
for download and installation instructions.

PackMan is a package manager front end for packages distributed
using the RISC OS Packaging Project (see http://www.riscpkg.org).

Its features include:

- Summary and detailed description of the packages
- Filters to allow display of packages for a specific category,
what’s installed, what’s new or upgrades to already installed
packages.
- Search for a package.
- Single buttons to start an install, upgrade or removal of a package.
- Menu option to upgrade all your packages at once.
- Automatically install dependencies for you, always showing what
is going to be installed.
- Install multiple packages at once.
- Install the components from a packages to your own location.

PackMan is open source software and it’s source code is on GitHub.
Suggestions/Contributions are always welcome. This doesn’t have to
be code, previously graphics, window layout and documentation fixes
have been contributed.

System requirements

RISC OS 4.0 or greater with long filenames
Internet connection for downloading packages

The normal RISC OS Packaging project policy manual has not been
updated with the new fields yet. The latest version can be downloaded
using !PackMan or viewed at:
http://www.riscos.info/~abuckley/policy.html

I’m not sure if this was meant to happen, but…

After upgrading to PackMan 0.9.2, the list of packages no longer mentions PackMan itself. There’s a completely blank line (apart from the “question mark” icon) where the entry for PackMan ought to be. I added the URL http://packages.riscosopen.org/packages/pkg/programs-armv5 as requested, but to no avail (on further checking I already had that URL under its “raspberrypi” alias).

(Raspberry Pi 3B+, RISC OS 5.26)

Re – blank PackMan entry in PackMan

I’ve tried this now and seem to get the same result on my Raspberry Pi 3. I can’t see a reason for it.

Can you just tell me the date that Help,Info…shows?

Can you try closing PackMan, restarting it and then running Update Lists again?

This fixed it for me. I’d be interested if it does for you.

If it doesn’t can you email me on my address in the PackMan help file and I’ll probably ask for a few files off your machine.

There’s a completely blank line (apart from the “question mark” icon) where the entry for PackMan ought to be.

The first time I upgraded I didn’t see this, but PackMan did install to Apps.Packman rather than where it was being run from Apps.Admin.PackMan.

The second time from a different SD card I triggered the blank line by updating the list whilst still running the old version, then switching to the new version the blank line could be seen. The blank line disappeared on refreshing the list with the new version.

Has anyone else experienced the new version of Packman installing to Apps.Packman versus where it was placed and run from?

This fixed it for me. I’d be interested if it does for you.

Nope, didn’t work. Going to email…

I have a few blank lines on my machine too.

There was one right at the top of the list, but doing an Update Lists and restarting got rid of it. The others are:

• Between Bzip2 and Cache
• Between LibJpeg-Progs and LibJPEG8-Dev
• Between PackIt and Patch (so this one’s PackMan itself)
• Between ZLib-Dev and ZLib1g-Dev.

I didn’t run into the ‘Admin’ issue mentioned above, but my PackMan was always directly in Apps.

I’m on a Pi 3 with OS 5.24.

I’ve now uploaded a fixed version 0.9.3 that should remove the disappearing PackMan problem.
I’m not sure how long it takes to get to the ROOL package lists. I suspect it will be there tomorrow if not later tonight.

If you have install 0.9.2, you can fix your install by updating the lists and then selecting Upgrade All. If PackMan 0.9.3 is available it should appear and you can then upgrade to it. After closing and re-opening PackMan it should appear in the package lists as expected.

0.9.3 installed and working. Thanks for fixing the bug!

On an ARMX6, I can report the same gaps as Chris Mahoney. After closing Packman and rebooting it I got different gaps, but it is behaving oddly in other ways. With both filters at “all”, the list claims that I Have downloaded every item in the list and they are all up to date, except of course the gaps. There seems to be a lot missing in the list, apart from the ‘gaps’, items that I don’t download.

I downloaded PackMan 0.9.3 from Alan’s site because of the blank line. On restarting Packman now at 0.9.3 the list reported it as still being 0.9.2 offering the upgrade, with dependency SharedULib 0.14. I upgraded, PackMan looks to have gone into the specified location but there was an empty Apps.Admin directory and it overwrote my SharedULib 0.15 with 0.14. I thought it was supposed to not overwrite in this case. Having retrieved SharedULib 0.15 PackMan reported 0.14 present with 0.15 available, I installed that to correct the reported status only to find 0.14 was back again but PackMan is reporting 0.15 as present. 0.15 has been retrieved for a second time.

And :-

Time: Sun Mar  8 20:31:30 2020
Location: Application space
Current Wimp task: Package Manager
Last app to start: Filer_Action

R0  = 00000000 R1  = d0014ee2 R2  = 00000000 R3  = 00000000
R4  = 004fa818 R5  = 00000000 R6  = 0040ad44 R7  = 004fa890
R8  = 0000000b R9  = 00402300 R10 = 0040a208 R11 = 0040ad40
R12 = 0040accc R13 = 0040ad18 R14 = 000db3b0 R15 = 0004a71c
DFAR = 00000004  Mode USR32  Flags nZCv if   PSR = 60000010

0004a6d4 : e2800068 : ADD     R0,R0,#&68         ; ="h"
0004a6d8 : e1a01005 : MOV     R1,R5
0004a6dc : eb02435c : BL      &000DB454
0004a6e0 : e2847078 : ADD     R7,R4,#&78         ; ="x"
0004a6e4 : e2840070 : ADD     R0,R4,#&70         ; ="p"
0004a6e8 : e1a01005 : MOV     R1,R5
0004a6ec : eb024358 : BL      &000DB454
0004a6f0 : e1a00007 : MOV     R0,R7
0004a6f4 : e1a01005 : MOV     R1,R5
0004a6f8 : eb024355 : BL      &000DB454
0004a6fc : e3550000 : CMP     R5,#0
0004a700 : 1affffed : BNE     &0004A6BC
0004a704 : e5962008 : LDR     R2,[R6,#8]
0004a708 : e594308c : LDR     R3,[R4,#140]
0004a70c : e5922014 : LDR     R2,[R2,#20]
0004a710 : e0833182 : ADD     R3,R3,R2,LSL #3
0004a714 * e5d31004 * LDRB    R1,[R3,#4]
0004a718 : e59f2088 : LDR     R2,&0004A7A8
0004a71c : e59f3088 : LDR     R3,&0004A7AC
0004a720 : e3510000 : CMP     R1,#0
0004a724 : 01a01002 : MOVEQ   R1,R2
0004a728 : 11a01003 : MOVNE   R1,R3
0004a72c : e28d2008 : ADD     R2,R13,#8
0004a730 : e28d0004 : ADD     R0,R13,#4
0004a734 : eb016da4 : BL      &000A5DCC
0004a738 : e1a00007 : MOV     R0,R7
0004a73c : e3a01080 : MOV     R1,#&80            ; ="Ä"
0004a740 : e28d2004 : ADD     R2,R13,#4
0004a744 : eb01cdcc : BL      &000BDE7C
0004a748 : e59d5004 : LDR     R5,[R13,#4]
0004a74c : e59f305c : LDR     R3,&0004A7B0
0004a750 : e245500c : SUB     R5,R5,#&0C         ; =12

R15 = 0004a71c = +4271c in application memory = _ZN13SourcesWindow20scrolllist_selectionERKN3tbx24ScrollListSelectionEventE +94
R14_usr = 000db3b0 = +d33b0 in application memory = _ZN3tbx6Gadget10clear_flagEj +90
          Function call to 00334c9c = +32cc9c in application memory = _kernel_swi +0

Has anyone else experienced the new version of Packman installing to Apps.Packman versus where it was placed and run from?

If you already had a version of PackMan installed it will update it to the previous install location. You can use the Move option in the Components, View menu to tell PackMan it’s new location (it may prompt for a backup during this process)

David Lane – have you tried upgrade to 0.9.3 as mention above. Once you have please close PackMan, re-open it and do an update lists. Does this get rid of the Gaps?

David Pitt – I didn’t even know there was a SharedULib 0.15, there’s not a package for it. Where did it come from?

Having said that PackMan isn’t supposed to be overwriting modules with a higher number anyway.

What machine/version of RISC OS are you using?

The crash seems to be in the Advanced, Sources window – Is that correct? If so had you just clicked on an entry?

I’ve updated PackMan to 0.9.3 and the blanks have gone away. When I did the update it also installed CaCertificates and a couple of other packages, and I think these are the ones that were coming up blank.

However, another issue. I’ve produced new versions of my packages with the Environment value specified. I only have two packages: Seasonal and Uptime. Seasonal was not actually installed on my system, and the ‘?’ icon disappeared from PackMan and all looks well. Uptime, on the other hand, was already installed, and the ‘?’ was still present. If I opened the Information window, the Environment wasn’t listed and the Standards version was still listed as 0.5.0 despite being 0.6.0 in the latest package. The package URL was also blank.

After using PackMan to install the latest version the ‘?’ went away, the Standards version is now showing as 0.6.0, and the URL is listed. It appears that locally-installed packages may be overriding part of the data from the server.

I didn’t even know there was a SharedULib 0.15, there’s not a package for it. Where did it come from?

It comes from a home built gcc.

*Help SharedUnixLibrary
==> Help on keyword SharedUnixLibrary
Module is: SharedUnixLibrary       1.15 (10 Feb 2019) (C) UnixLib Developers, 2001-2019

PackMan isn’t supposed to be overwriting modules with a higher number anyway.

It doesn’t, usually, so this occurrence was unexpected.

What machine/version of RISC OS are you using?

Platform      : Titanium
*FX0
RISC OS 5.27 (07 Mar 2020)

The crash seems to be in the Advanced, Sources window – Is that correct? If so had you just clicked on an entry?

Probably. The catch is that ZeroPain logs appear silently on a covered filer window so are not instantly obvious. I cannot reproduce the pain now.

Now I have a blank line in PackMan’s main window where the SharedUnixLibrary should be and this file in Cache !Packages.Cache.SharedUnixLibrary_1/15-1. I thought Cache was for incoming downloads. If so I cannot find now where that could have come from, but anyway it actually only contains 0.14.

I have now completely deleted and then reinstalled PackMan with no issues at all. PackMan knows where it is and there was no SharedUnixLibrary clash. It was then necessary to reinstate my previous PackMan installs, all one of them, so that the new PackMan installation knows about it. DirSync downloaded and a backup was made of the version already present.

I don’t know what was causing the earlier bother, but it did get worse. A zero length file called – was found in Cache, after deleting it PackMan seemed not be able to find !Packages and was asking to install that. PackMan was quit hoping to restart it but it would not saying PackMan was already running, which it was, it was in the TaskManager but was not on the iconbar. At this point it all seemed too bizarre so I did the only decent thing and started again from scratch.

Dilemma…do I flag 26bit games as arm26 or arm as they’re being fixed at runtime?

Second problem is how to update hundreds of packages without creating a version bump and hundreds of unnecessary package updates? The third problem is how to get the Environment value into the packages in the first place.

I might have to continue this via eMail as the CSV used to generate the packages does contain a column for ARMv5 compatibility (Y=32 bit, F=26 bit fixed at runtime), so it might need a tweak to the packaging tool you coded for me.

David Pitt – sorry about the trouble you’ve had. I’m glad you’re up and running now.
I’m experimenting to see if I can see what happened. It may take a while though. If the problems re-occur please let me know.

Chris Mahony – I’ll have to try to reproduce your problem here. I think you’ve given me enough information for me to try.

Jon,

Dilemma…do I flag 26bit games as arm26 or arm as they’re being fixed at runtime?

I would flag them as arm, but make sure they have a dependency on ADFFS if they need it to run on 32 bit systems. It’s what they run on that’s important and if that requires another module then as long as that’s set as a dependency that’s fine.

You’re other questions we are probably better taking to email. It sounds like you have a column that can be used to calculate the environment. I can’t remember what causes version bumps at the moment, but we may be able to get away with just creating a new package with the same version number, but with the environment set.

I am now running version 0.9.3; but, with both filters on “all” in the Packman window, every line has a green tick! So, according to Packman, I have installed every available package! I never installed everything on the list, and looking at it, it seems it is lisitng only stuff I have installed. It would help to know whether the list of available packages can be seen somewhere to confirm this. Update Lists doesn’t make any difference to what I am seeing.

I am now running version 0.9.3; but, with both filters on “all” in the Packman window, every line has a green tick! So, according to Packman, I have installed every available package! I never installed everything on the list, and looking at it, it seems it is lisitng only stuff I have installed. It would help to know whether the list of available packages can be seen somewhere to confirm this. Update Lists doesn’t make any difference to what I am seeing.

It looks like it’s not downloading anything from the package lists. Can you go into the sources menu option and check that it includes the places you expect?

On the Advanced menu their is a View Log button, select that once to turn on logging, then do an update lists and it should show what it is trying. If the problem isn’t obvious from that send me the log file to my email address in PackMan and I’ll have a look at it.

Have had an installation of Packman for a good while and found it to work reliably for the few packages I used it for.

I have tried to get Packman to update correctly and completely failed this evening. Upgrading failed in the same way as others have already noted. This was on an ARMX6.

I had an installed but never used version of 0.9.1 on the Titanium. This also failed to update.

I downloaded the latest version (0.9.3) direct and made a completely clean installation on the ARMX6, removing all the existing !Packages resource and all choices files before starting. Ran that, which first installed the default !Packages in to Boot:Resources. Attempting to update the lists fetches nothing (the update window appears for what must be a few centisecs before showing done) and the lists still show just Packman itself. There seems to be a problem with actually fetching new lists, since all attempts on both machines gave an immediate ‘Done’ but nothing new appears. The sources file looks ok.

I will try tomorrow with logging active.

I found that the uncommented lines in the the Sources file were not the same as on my Pandaboard: The line ending armv7 was missing from the ARMX6 and present on the Pandaboard running Packman version 0.9.1. On the other hand, the line ending thirdparty wass present on the ARMX6, but missing from the Pandaboard. I copied in the line ending armv7 to Packman version 0.9.2 sources file running on the ARMX6. This didn’t make any difference even after a re-boot.

I can confirm what Chris Johnson experienced that nothing seems to happen when you do an “update lists”.

I turned logging on, clicked on ‘update lists’ and below is the saved out file.

15:00:53 30000 Reading list of sources from disc
15:00:53 30001 Downloading source lists
15:00:53 30004 All sources downloaded
15:00:53 30006 Packages from downloaded sources added to available list
15:00:53 30007 Adding local packages
15:00:53 30008 Updating package database
15:00:53 30009 Package database update completed

Comment: The time is out by about 2 hours, 2 hours ahead, and the column headings and code column were not there in the “Log Viewer” window.

I can confirm what Chris Johnson experienced that nothing seems to happen when you do an “update lists”.

I turned logging on, clicked on ‘update lists’ and below is the saved out file.

The log is showing that it’s not finding downloading any sources.

Can you send me the Sources file from your !Boot.Choices.PackMan file?
I will then copy that over my copy here and see if I can duplicate your problem.

What timezone are you in? Could the times be UTC? Also check your time in RISC OS is correct.