making a unix release package

Now that I can actually make Pi VMs with or without the fast blt at will, I'd like to be able to assemble a package that I can send out to a few people for testing. I feel sure there used to be a makefile target to do this but can't spot anything that appears appropriate in the current setup.

So how does one do it these days?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
I do not fear computers.  I fear the lack of them.

 
On Thu, Jun 27, 2013 at 10:28:42AM -0700, tim Rowledge wrote:
>
> Now that I can actually make Pi VMs with or without the fast blt at will, I'd like to be able to assemble a package that I can send out to a few people for testing. I feel sure there used to be a makefile target to do this but can't spot anything that appears appropriate in the current setup.
>
> So how does one do it these days?
>

I don't know how to do it the right way, but if you are in a hurry
and don't mind doing it the wrong way, just do a "make install" and
tar up the results. I am away and can't give you the specifics, but
I'll try to follow up later.

Are you doing an interpreter VM, a stack VM, or both?

Dave

On 27 June 2013 20:19, David T. Lewis <[hidden email]> wrote:
A slightly better quick-and-dirty way is to use checkinstall:
http://wiki.debian.org/CheckInstall

Alex

On 27-06-2013, at 12:19 PM, "David T. Lewis" <[hidden email]> wrote:

Just the plain interp right now. Scratch is nowhere near ready for the stack/cog world yet.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Calling her stupid would be an insult to stupid people.

 

On 27-06-2013, at 12:51 PM, Alex Bradbury <[hidden email]> wrote:
>>
>
> A slightly better quick-and-dirty way is to use checkinstall:
> http://wiki.debian.org/CheckInstall

An interesting idea. Seems a pity it doesn't do simple tar/gzip/thingies.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Close your eyes and press escape three times.

 
On Thu, Jun 27, 2013 at 01:06:02PM -0700, tim Rowledge wrote:
Here is a crude but effective recipe:

First build the VM and install it in the normal way:

$ make install

The installation directory is determined by the SVN version and VMM versionString,
so check it, for example like this:

$  squeak -version
4.12.5-2744 #1 XShm Sat Jun 22 20:10:52 EDT 2013 gcc 4.5.0
Linux linux-jh8m 2.6.34.10-0.6-desktop #1 SMP PREEMPT 2011-12-13 18:27:38 +0100 x86_64 x86_64 x86_64 GNU/Linux
plugin path: /usr/local/lib/squeak/4.12.5-2744 [default: /usr/local/lib/squeak/4.12.5-2744/]

Make a tar archive. Use relative paths in the archive so the the archive can be unpacked in any relative location. So:

$ cd /usr/local
$ tar czvf /tmp/Squeak-tpr-4.1.2.5.2744.tgz lib/squeak/4.10.2-2614 bin/squeak bin/squeak.sh share/man/man1/squeak.1

This will create a file in /tmp called Squeak-tpr-4.1.2.5.2744.tgz that contains
more or less the same files that Ian puts into a standard distribution. Note, the
".tgz" suffix indicates that it is a compressed tar (the "z" option in the tar
command) as opposed to a normal uncompressed tar file, for which you would use
the suffix ".tar".

You can unpack the tar file anywhere you want. To install it in the normal location,
cd to /usr/local and unpack the tar ($ tar xzvf /tmp/Squeak-tpr-4.1.2.5.2744.tgz).

If you want to run the VM in some other directory, unpack it there:
$ cd my/temp/directory
$ tar xzvf /tmp/Squeak-tpr-4.1.2.5.2744.tgz

In that case, you will want to run the VM directly from within its own directory
so that the plugins will be located properly (since they are not in the expected
installation directory compiled in to the VM). So in this cases, the VM proper
will be in my/tmp/directory/lib/squeak/4.10.2-2614/

So for example you can put your image, changes, and sources file in that directory
and run the image with the squeakvm executable in that directory.

Depending on how you intend your victims to use the test VM, you may find it simpler
to distribute just that actual VM files (the contents of the lib/squeak/4.10.2-2614/
directory in this example) and run the Scratch image from a directory containing
all of those files.

Dave

 

On 28-06-2013, at 5:07 AM, David T. Lewis <[hidden email]> wrote:
>
> Here is a crude but effective recipe:


Thanks Dave. I'll give that a go.

It never ceases to amaze how insanely complicated unix makes everything.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Been playing with the pharmacy section again.

 
On 28 June 2013 21:52, tim Rowledge <[hidden email]> wrote: Amen, brother.

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- Been playing with the pharmacy section again.
>
>



--
Best regards,
Igor Stasenko.

 
On Sat, Jun 29, 2013 at 12:39:05AM +0200, Igor Stasenko wrote:
<OT>
I understand what you are saying, but ... I think that the only part of my
recipe that had anything to do with Unix is the notion of mapping "files"
into a tree-structured directory with a single root at "/". That hardly
strikes me as being insanely complicated. In fact it is a great simplification
compared to the other bodged-up and overcomplicated arrangements found in
other operating systems over the years. Of course an even greater simplification
might be to not use the file metaphor at all, but if you do insist on using
files, it's hard to imagine a more conceptually simple representation than
the one provided by Unix.

Having said that, Smalltalk is the only environment I can think of that does
not inherently insist on represent things as "files" ... so what do people
spend their time on in Smalltalk? Griping about how well or poorly the image
maps to the various insanely complicated, inconsistently implemented, and
conceptually archaic "file system" metaphors used by their favorite operating
system platforms. Go figure.
</OT>

Dave