[squeak-dev] Ubuntu package maintainers help
bert at freudenbergs.de
Thu Apr 16 10:02:17 UTC 2009
On 16.04.2009, at 05:17, Jerome Peace wrote:
>> From bert's thread Linux package maintainers need help...
>> Bert Freudenberg bert at freudenbergs.de
>> Wed Apr 15 13:19:45 UTC 2009 wrote:
>> In the closed-source world (Mac, Win) typically the software authors
>> provide binary packages for end users. This is even true for open-
>> source software on these platforms, the authors provide ready-to-
>> install packages, separate from with the source code. That's why we
>> have Windows and Mac downloads on our website. It's a one-size-fits-
>> all approach, and all work is done by the authors.
> I would like to see something like this for Ubuntu. I think it is a
> good place to start. It gives a reasonable goal to shoot for.
> Lessons learned can then be applied to other squeak distro's one by
That already exists, but maybe Matej could need a hand:
>> Not so in Linux. Here, building the binary packages that fit into a
>> specific Linux distribution is typically done by users of that Linux
> That was not true of the etoys installation from squeakland. It does
> not have to be true for distro's squeak.org supplies.
Squeakland should provide only Mac and Win installers, and work with
the distros to carry an up-to-date Etoys package.
Right now there also is an RPM and a DEB package at squeakland, but I
see that as a thing of the past. It already leads to confusion when
people try to combine those packages with the ones from their distro.
The squeakland packages are not even a good model how to package Etoys
but more of a hack.
>> These volunteers ("package maintainers") take the source code
>> from an "upstream" author and make a binary package from that,
>> typically by writing a few scripts that compile and install the
>> software in the right place and with the right supporting files
>> may be different for each Linux distribution).
> Yes, and to a certain extent that is out of our control. And only
> under our influence if those in direct control wish to allow it.
> Chris's complaint to Ubuntu about sound in the squeak distribution
> will be a year old in May. Even though a solution is known the
> action to fix it has not happened.
Yes, and I don't know why. However, providing our own packages to me
is not much better than simply compiling from source. It's a
workaround rather than a fix.
>> Because of these volunteers it is that you can simply install about
>> *any* free software from your distro's "software installer". Every
>> single one of these thousands of packages was added and is maintained
>> by someone.
>> As you can guess, package maintainers are usually no experts in the
>> software they package. They will try the canonical "./configure;
>> make install" command, and if that appears to work they make a
>> from that, do a few tweaks maybe and release it. People can install
>> that package easily now, and everything appears to be fine.
> Umm. Part of the problem is the need for a smoke test that shows the
> problem early.
> Squeak on loading should show off and sound off. That we can work on.
> Then when things don't work they won't appear to work.
Good suggestion. How to invoke a smoke test should be part of the
>> Now what needs to happen is that a user who discovers that sound is
>> not working must file a bug report for the package *maintainer*.
> Chris did exactly that. See above.
I know, and I acknowledged that. My long post was about illustrating
the whole picture.
>> with the author (us), because that would bypass the maintainer. So
>> your distro's bug tracker, not bugs.squeak.org.
> Um. There is a problem of multiplicity.
Which is considered a Good Thing in the volunteer-driven open source
> Each distro has its own tracker. Trackers don't insure action will
> be taken.
Right. That's what "voluntary work" means.
> What the distro's won't do, we have no control over.
"The distro" won't do anything. You need to get that out of your head.
"The distro" is the sum of the people working on it. Become part of
that community. Participate in mailing lists. Let the maintainers know
what works and is already helpful (!) and what does not. One of the
things why maintainers put in work is because of recognition within
> Still, as a developer, I want my work distributed on fully working
> squeak systems.
> How might this be done by things within our control?
If you are shipping your own application you have to include a VM.
That's the only safe bet. At least until distro packages are mature,
but depending on your app maybe even then.
> One activity the board should support with re$ource$ is a routine
> fresh installation
> of squeak from key distros to see if they can pass a smoke test.
> Where problems are found more frequent tests should be scheduled
> until things are in a good state.
> In choosing key distros the 20-80 rule should apply.
I don't exactly see how money would help here. But starting a page on
squeak.org with this information, gathered by volunteers and kept up-
to-date would be a Very Good Thing.
>> Maybe having a mailing list specifically for maintainers would be
> With all the bug trackers out there we should have a mail list to
> monitor and collect bug updates from them.
> AFAIK tell Ubuntu tracks bugs separately from Debian on which it is
Not a bad idea. Not sure how easy that would be. Some bug trackers
(like launchpad) allow to subscribe to all events on a particular
package, others (the Trac installations I know) don't.
Some trackers allow to track upstream issues, that is, a distro
maintainer would link the distro bug report with an upstream bug report.
>> But even just tracking down what packages are already out
>> there, who is maintaining them etc. would be very valuable. And
>> monitoring the bug trackers, participating on the distro-maintainers
>> lists etc. Here is just a short list for squeak packages in various
> That was a useful collection.
It was just 10 minutes spent with google, but thanks ;)
> I have started by joining and chiming in on Ubuntu.
>> Squeakers have been pretty much ignorant of the larger open-source
>> community in the past. But I think there is a lot to be gained by
>> becoming a proper part of it. I have been working towards that goal
>> for a while now, in particular as part of the OLPC / Sugar
>> efforts. Etoys is distributed as part of Sugar and depends on an up-
>> date Squeak-VM package, so we do have allies in the Sugar
>> And everyone can help - as I wrote above, no deep VM knowledge is
>> necessary to monitor bug trackers or keep contact with the
> Theres another thing to say here. A vm gets distributed with etoys.
> It has the necessary plugins. It can be used instead of a squeak vm.
I don't really see how that is relevant. If you download a VM from
squeakvm.org that would work too.
> There are some considerations that have to be addressed.
> These are the difference between the dialog box when the window
> close button is hit.
Which is an image issue, as I mentioned several times. Unless someone
contributes a VM patch to optionally restore the old behavior, which
was to kill the image and loose everything without asking.
> If that were taken care of then AFAIK all you would need would be a
> shell script for launching squeak images using the etoys vm.
Which is totally besides the point. But hope you get my drift by now.
> There is one more issue that needs to be addressed.
> Our download website is overloaded with information.
> And while mac and window users have a path forward.
> Linux users are expected to make TOO many decisions
> Decisions based on information they lack.
> So that needs simplifing and sorting as well.
I'm sure the web team would be happy to get a proposal from you.
> So in sum:
> Fruitful efforts are to
> 1) make etoys and squeak more compatible with etoys vm package.
> 2) Simplify and clean up the linux download web page(s).
> As Bert said:
>> So there. Who else wants to get involved?
Hehe. Indeed. But I think we're onto something.
- Bert -
More information about the Squeak-dev