Hi Is it possible to set messages from the group to have a reply to the group option? I recently used googlemail to reply to Alan Buckley's post about the new front end he is working on, and it all went directly to him, and other group members might have been interested. Thanks -- -- Jess Iyonix
For many years I've been slowly working towards an alternative package manager to !RiscPkg. Having got so far, but suffered a slight lack of enthusiasm, I thought I would make the very early alpha version available for people to download and comment on so I can decide if it's worth continuing. It can be downloaded from: http://alanb.drobe.co.uk/packman.zip How to use it and contact me with feedback is in the !Help file. I'm sure people won't mind comments on this list if you prefer. It is an alpha version so it may crash and it needs !RiscPkg to have been installed and working or it won't be able to do anything. Theoretically it shouldn't mess up your existing packages and you should be able to use !RiscPkg to tidy up if it crashes during an install. All comments are welcome, but I know how everyone will want a different UI, so if you feel it does need a radically different UI please also let me know if you find the(Continue reading)
On Sat, Oct 24, 2009 at 02:25, Graham Shaw <gdshaw@...> wrote: > Packages containing more than one application would be easy enough to avoid > by splitting them into multiple packages. > > However, you would loose a significant amount of flexibility not being able > to: > - split applications between multiple packages > - have empty packages which exist solely to pull in dependencies. > > I'm not saying this couldn't be made to work, but it would really be more of > an 'application manager' than a 'package manager'. Well, this wouldn't necessarily supplant the current package format - many things simply wouldn't be able to use this format. However, applications with a single application inside would be able to use it. > The other major difficulty would be the fairly large amount of work needed > to implement these features, but if someone wants to try then far be it from > me to stop them. > > What you could perhaps do in a reasonable amount of time would be: > - Have a site for downloading 'stub' applications, which the user can place > where he wishes. > - When first run, the stub application invokes RiscPkg to download the real > copy of the application + dependencies, which would be stored using the > existing package file format. > - When run subsequently, the stub invokes the real copy. > > This would have almost the same behaviour from a user POV (provided he > didn't inquire too closely into what was going on behind the scenes) and(Continue reading)
I was tossing this idea around, and it was suggested that I post it here, so here goes. This might not work in all situations, either, but for an application where there's just one app that goes into a directory (read: most apps,) and nothing else, this would work. Rather than have the package contain a hierarchy of directories, and the application to be installed being in one of those directories... have the application be the only directory at the root level of the package ZIP file, with the RiscPkg info inside the application. Then, the user can copy the application to the drive, in whatever location, and run it. Upon first run, the application would invoke the package manager, to download any necessary dependencies, and register the app in the package database. This could even handle moving the app, by comparing the directory it was originally installed in, with the <Obey$Dir> on run, and if different, notifying the package manager of the change. Deletion would be more difficult, but probably possible to detect. Worst case, on every package manager operation, you scan for changes. This could also be implemented in downloading apps from a repository - just drag from the list of apps in the repository right to the directory you want to install in. Just a thought...
I've added a package for Harriet Bazley's Textseek program which searches for text in a directory of files. As this used the SlidingHeap module by Steven Haslam I've also created a Dev and runtime package for this. This module provides some useful memory handling routines. Thanks to Harriet Bazley and Derek Haslam for allowing me to produce these packages. Regards, Alan Buckley _________________________________________________________________ Celebrate a decade of Messenger with free winks, emoticons, display pics, and more. http://clk.atdmt.com/UKM/go/157562755/direct/01/
I'm proposing to replace the UnixLib package that contains the SharedUnixLibrary module with a package called SharedUnixLibrary. The main differences between the packages are: 1. The package name has changed 2. The package version will be the version of the SharedUnixLibrary module. 3. The SharedUnixLibrary will be installed into !System as it is when people install it by hand, instead of a !UnixLib directory. The main advantage of this change will be that we should end up with only one copy of the SharedUnixLibrary on a users system. The main disadvantage is that if the SharedUnixLibrary is already installed when the packaging system is first deployed (or first tries to install a package that requires it) the user will have to move the existing SharedUnixLibrary out of the way as it will show up in the conflicts window. GCC4 will be modified so that it no longer looks for the SharedUnixLibrary in the !UnixLib directory. Initially the new package will appear when the GCCSDK4 packages appear on the autobuilder site. It is my intention to add it to the main RiscPkg site after that. I don't believe this should effect any older packages that have already been created as they will still be able to use(Continue reading)
I've released version 0.4.0 of RiscPkg and version 0.3.0 of LibPkg. Significant changes include: - Support for tilde character in version numbers; - Addition of package information dialogue box (with thanks to Alan Buckley); - New icons for the !RiscPkg and !Packages application directories (with thanks to Richard Hallas); - Various cosmetic improvements. The new versions are downloadable using RiscPkg. Source code is in the usual place. -- -- Graham Shaw (http://www.riscpkg.org/~gdshaw/)
I am trying to determine the best way to distribute the SharedUnixLibrary via a riscpkg package for GCC 4. In looking into this I notice there are two different ways of distributing it at the moment. 1) The riscpkg site has a package called UnixLib, with the version being the libunixlib version and installs it into a !UnixLib directory. 2) The Netsurf packages use a package called SharedUnixLibrary with the modules version which they install into System. It would probably be sensible to standardise on a single way of distributing the SharedUnixLibrary. I wonder if the people who created these packages could comment on why the packages were created this way. Anyone else is of course welcome to comment on any preferences to how it should be packaged. This has been posted to the gccsdk, riscpkg and netsurf lists as it is relevant to all three. Sorry for the overlap for people (like myself) that subscribe to all three. Thanks, Alan(Continue reading)
Hi all, Ive fixed all the packages Ive produced so they should actually work now. Ive tested them locally with WebJames but because my Acorn has no internet connection I cant be sure if theyll work in the real world. If anyone would like to test my packages, just edit <Choices$Write>.RiscPkg.Sources to include the following line of text: pkg http://www4.webng.com/resurgam/Packages/Unstable.txt Cheers, James. __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Hello! I've not really used RISC OS for a few years now but have just got VA for Mac. I'm trying to install !RiscPkg on the virtual machine but am repeatedly getting errors regarding address resolution i.e. the 'Downloading' dialog box returns: Failed Couldn't resolve host 'www.riskpkg.org' Netsurf can access the site quite normally. I've tried downloading the package feed and moving it to: <!Boot>.Resources.!Packages.Available It's read correctly but again on trying to install the latest version of the package manager I get the DNS resolution error on 'Commit'. I wondering whether there's a problem with libcurl but I don't know enough about the details of how linux apps and particularly shared objects end up working on RISC OS to find out... Sorry if this is something that's come up before but I couldn't see it in the mailing list archives. Any suggestions would be appreciated(Continue reading)Cheers, Daniel.
Trying to update the package list this morning, I get an error message - 'Failed illegal character in upstream version'. Removing pkg http://www.riscos.info/packages/pkg/autobuilt from Choices:RiscPkg.Sources allows an update without error. Can anyone shed any light on this? Evan.
 |
|
|
|
|
|
|
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
RSS Feed4 | |
|---|---|
2 | |
1 | |
1 | |
2 | |
3 | |
13 | |
8 | |
2 | |
6 | |
11 | |
11 | |
15 | |
9 | |
13 | |
38 | |
6 | |
4 | |
5 | |
24 | |
77 | |
15 | |
17 | |
3 | |
2 | |
36 | |
34 | |
1 | |
43 | |
14 | |
2 |