Cog binary + cogdeb.zip = Cog.deb

https://www.dropbox.com/s/smsqoib0dnjjsg8/cogdeb.zip
https://www.dropbox.com/s/qyp63erz3152ntt/cogvm_2776-1_i386.deb

Ken created a tool for taking a mirandabanda binary, placing a Makefile, and producing a cog<versionfoo>.deb. I found it in his box4 directory as a byproduct of his installing Cog there. It comes with a README file and is quite simple. It's exactly what I was looking for. I've also included a the deb he generated in case anybody wants to skip the process and just install Cog 2776.

Chris

On 17 June 2014 19:19, Chris Cunnington <[hidden email]> wrote:
> https://www.dropbox.com/s/smsqoib0dnjjsg8/cogdeb.zip
> https://www.dropbox.com/s/qyp63erz3152ntt/cogvm_2776-1_i386.deb
>
> Ken created a tool for taking a mirandabanda binary, placing a Makefile, and producing a cog<versionfoo>.deb. I found it in his box4 directory as a byproduct of his installing Cog there. It comes with a README file and is quite simple. It's exactly what I was looking for. I've also included a the deb he generated in case anybody wants to skip the process and just install Cog 2776.

Nice! Seems like just a few short steps from automatically producing
debs from released Cogs in build.squeak.org... Any takers?

frank

> Chris

On Tue, Jun 17, 2014 at 10:12:53PM +0100, Frank Shearar wrote:
> On 17 June 2014 19:19, Chris Cunnington <[hidden email]> wrote:
> > https://www.dropbox.com/s/smsqoib0dnjjsg8/cogdeb.zip
> > https://www.dropbox.com/s/qyp63erz3152ntt/cogvm_2776-1_i386.deb
> >
> > Ken created a tool for taking a mirandabanda binary, placing a Makefile, and producing a cog<versionfoo>.deb. I found it in his box4 directory as a byproduct of his installing Cog there. It comes with a README file and is quite simple. It's exactly what I was looking for. I've also included a the deb he generated in case anybody wants to skip the process and just install Cog 2776.
>
> Nice! Seems like just a few short steps from automatically producing
> debs from released Cogs in build.squeak.org... Any takers?
>

Generating VM builds for general distribution on build.squeak.org is a Really
Bad Idea. Please do not do that.

If we are going to do something with automated builds, it should happen on
squeakvm.org or on something closely associated with it, and it should be done
with the approval of the platform maintainers. In this case, you are talking about
setting up a distribution of Eliot's VM executables. If Eliot says that he wants
you to do this for him, then consider yourself empowered. Otherwise do not do it,
and especially please do not do it on build.squeak.org.

I put a couple of jobs on build.squeak.org to test the process of code generation
with VMMaker. These are documented in the Jenkins job descriptions, and they do
serve a useful purpose. But if it is generating too much confusion, then I will
just get rid of them.

Thanks,
Dave
 

On 2014-06-17 6:56 PM, David T. Lewis wrote:
> Generating VM builds for general distribution on build.squeak.org is a Really
> Bad Idea. Please do not do that.

Can you expand on this, please? Why is it such a Very Bad Idea?

Tony

On Tue, Jun 17, 2014 at 07:00:30PM -0400, Tony Garnock-Jones wrote:
> On 2014-06-17 6:56 PM, David T. Lewis wrote:
> > Generating VM builds for general distribution on build.squeak.org is a Really
> > Bad Idea. Please do not do that.
>
> Can you expand on this, please? Why is it such a Very Bad Idea?
>

The authors and maintainers of the VMs for various platforms put a lot
of time and effort into producing reliable products, and in trying to do
so in such a way that they have some reasonable chance of answering questions
when things do not work. Setting up a random bunch of undocumented and unsupported
variations on those VMs makes life difficult for the people who are creating
and supporting them, and especially so if those undocumented distributions
are being served from a site that has "squeak.org" in its name.

It's great to experiment, but let's have some consideration for the authors
and maintainers of the VMs, and let's be careful that the things that we
present to the world on squeak.org have real credibility and the best possible
support.

Dave

On 06/17/2014 07:19 PM, David T. Lewis wrote:
Thanks. Those are good points.

Tony

On 18.06.2014, at 02:51, Eliot Miranda <[hidden email]> wrote:

> I'm not so concerned in this case because it looks like it is just a repackaging of a prebuilt VM.  What would be nice is if this approach is documented and replicated for other distros.  Then we have something we can allow distro maintainers to take wen they want to build an install artifact for a particular distro (if that doesn't sound hopelessly circular).

Linux distros never package binaries compiled by someone else (*). What they need is a source tar ball that builds cleanly, and a list of dependencies.

- Bert -

(*) which is a major reason why we're having a hard time to get Squeak images into distros (as opposed to Squeak VMs). The image looks like a big binary blob to the average distro maintainer, and they want the real source instead.

On 18 June 2014 00:19, David T. Lewis <[hidden email]> wrote:
Using CI is exactly the opposite of "random", particularly if the
scripts that generate these artifacts are themselves blessed by said
VM maintainers.

Also, build.squeak.org doesn't produce artifacts for "general
distribution". I think anyone downloading an artifact from a CI server
and then complaining that the thing's not reliable gets exactly what's
coming to them: either they're prepared to test an alpha quality
thing, or we should tell them where to download the officially
supported versions.

What I don't want is for VM maintainers to have to waste their time
building things that a computer can do for them. Ideally, for
instance, I'd like to see a test that takes a brand new Cog VM, buids
a deb, installs that deb on a clean machine, and fires up an
officially sanctioned Squeak image (and Pharo, and Cuis, and NewSpeak
images for that matter). That way we can know that the deb actually
works.

> It's great to experiment, but let's have some consideration for the authors
> and maintainers of the VMs, and let's be careful that the things that we
> present to the world on squeak.org have real credibility and the best possible
> support.

I'm not sure how creating a deb automatically means disrespecting VM
maintainers. Why is credibility an issue? "Hey something broken in
this alpha version of a VM" says Random Newbie "Well if you can't
handle gdb, don't do that." says VM Maintainer. Producing these easily
consumed artifacts ought to help get more VM testers testing things,
instead of asking them to download source and learn the necessary
incantations.

I do deeply appreciate that VM maintainers jump through a great many
hoops in their work: Iam Piumarta keeps a whole pile of machines
running arcane OSes so he can test the Interpreter VM, for instance.

I just don't see why automating tedious tasks causes big problems.

frank

> Dave

On 18-06-2014, at 1:57 AM, Bert Freudenberg <[hidden email]> wrote:
>
> (*) which is a major reason why we're having a hard time to get Squeak images into distros (as opposed to Squeak VMs). The image looks like a big binary blob to the average distro maintainer, and they want the real source instead.

And of course they never include large binary lumps; no images, no sound files, no sirree we don’t do that. I sometimes have to wonder about these people.

Perhaps we should change to an image format that is an image? Make a jpeg or whatever and use the EXIF area for our data and put a screen snapshot as the picture?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Compromise, says Prof. Trefusis, is stalling between two fools

On Jun 18, 2014, at 5:49 AM, Frank Shearar <[hidden email]> wrote:

+1.  But who pays for the I frastructure, both "physical" and setting it up?  I like the idea that someone else in the community created a functional Debian install artifact.  The issue now is how to test and (if ok) deploy it at minimal cost to us all :-)

we actually can already do that, if the picture fits into 512 byte...

--
Tobias Pape
sent from a mobile device

On 18-06-2014, at 12:07 PM, Tobias Pape <[hidden email]> wrote:

> we actually can already do that, if the picture fits into 512 byte…

Ah, I see what you mean; the image header… hmm, not what I was thinking about actually. It looks like Exif couldn’t be used because of an apparent 64kb metadata limit (but Spoon image files might work…) so maybe some simple steganography would do the trick. Make a jpg (or whatever) that looks to image previewers etc like a screenshot but actually has our image embedded within. After all, release images are not so different in size to typical decent camera files.

Aside from the advantage of convincing linux release weenies to accept our image file (they’re just images folks!) you get a free screen preview picture to remind you what image this is. It’s a bargain!


tim
PS Random sigline-mystic provides us with a timely reminder as to why we want the build system as we do.
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Never do at  compile-time what you can put off till run-time