From bert's thread Linux package maintainers need help...
Bert Freudenberg bert at freudenbergs.de Wed Apr 15 13:19:45 UTC 2009 wrote:
<snip old stuff>
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 one.
Not so in Linux. Here, building the binary packages that fit into a specific Linux distribution is typically done by users of that Linux version.
That was not true of the etoys installation from squeakland. It does not have to be true for distro's squeak.org supplies.
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 (which 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.
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; make install" command, and if that appears to work they make a package 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.
Except it's not. E.g., unless the package builder declared a build- dependency on the "alsa-lib-devel" package (that's what it is called in Fedora anyway) the Squeak VM will be built without ALSA sound support. The "configure" script is smart enough to not build the "vm- sound-ALSA" plugin if it does not find the necessary files. It also writes out a message that the plugin was disabled. But that is easy to overlook, and also not fatal - there are good reasons for not wanting to build that plugin.
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.
Not with the author (us), because that would bypass the maintainer. So use your distro's bug tracker, not bugs.squeak.org.
Um. There is a problem of multiplicity. Each distro has its own tracker. Trackers don't insure action will be taken. See above. What the distro's won't do, we have no control over.
Still, as a developer, I want my work distributed on fully working squeak systems. How might this be done by things within our control?
The maintainer either fixes the problem, or opens an "upstream" bug with the authors. Sometimes it's even a chain of "upstreams", in Ubuntu's case the package may come from Debian, so a user would file a report at Ubuntu's tracker, the Ubuntu maintainer at Debian's tracker, and the Debian maintainer with us.
If instead we bypass the maintainers, we get precisely the chicken-and- egg problem we are in now. The distro packages do not work well, so the experienced developers do not use them but compile their own. Which leaves the packages in their bad state because nobody knowledgeable cares about them.
To be fair, in the "sound on Ubuntu" case in fact the proper procedure was followed: https://bugs.launchpad.net/ubuntu/+source/squeak-vm/+bug/235146 but apparently did not get fully resolved yet. Not sure what needs to happen next in this specific case. I've added to the report. We'll see if that gets a response.
But in general, we should try to make it as easy for package maintainers as possible. Even if it is just by letting them know that their package is used. So Squeak developers on Linux should try to use the distro's packages, and if they are insufficient, give feedback. Also, the source code should come with clear instructions on how to build it, what dependencies there are etc.
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.
Maybe having a mailing list specifically for maintainers would be useful?
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 based.
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 distros:
Debian: http://packages.debian.org/search?keywords=squeak-vm Fedora: https://admin.fedoraproject.org/pkgdb/packages/name/squeak-vm Ubuntu: https://launchpad.net/ubuntu/+source/squeak-vm OpenSuSE: http://download.opensuse.org/repositories/devel:/languages:/smalltalk/openSU... Gentoo: http://gentoo-portage.com/dev-lang/squeak Arch: http://aur.archlinux.org/packages.php?ID=13021
That was a useful collection.
I have started by joining and chiming in on Ubuntu. Six are too many to focus on at present.
The good news is that once there are "good" packages in the major Linux distributions, the smaller ones can follow suite much more easily. The big issues of e.g. what build dependencies exist are solved by then, and everyone can learn from each other.
+1. Focus on one. Learn our lessons. Spread the knowledge.
Part of the problem is that bugs once known are not being squashed in a timely fashion. The result is an infestation of problems.
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 development efforts. Etoys is distributed as part of Sugar and depends on an up-to- date Squeak-VM package, so we do have allies in the Sugar maintainers. And everyone can help - as I wrote above, no deep VM knowledge is necessary to monitor bug trackers or keep contact with the maintainers.
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. There are some considerations that have to be addressed. These are the difference between the dialog box when the window close button is hit. 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.
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.
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?
<snip>
Yours in curiosity and service, --Jerome Peace
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 one.
That already exists, but maybe Matej could need a hand:
http://wiki.squeak.org/squeak/3616
Not so in Linux. Here, building the binary packages that fit into a specific Linux distribution is typically done by users of that Linux version.
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 (which 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; make install" command, and if that appears to work they make a package 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 maintainer's guide.
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.
Not with the author (us), because that would bypass the maintainer. So use 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 world.
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 the community.
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 useful?
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 based.
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 distros:
Debian: http://packages.debian.org/search?keywords=squeak-vm Fedora: https://admin.fedoraproject.org/pkgdb/packages/name/squeak-vm Ubuntu: https://launchpad.net/ubuntu/+source/squeak-vm OpenSuSE: http://download.opensuse.org/repositories/devel:/languages:/smalltalk/openSU... Gentoo: http://gentoo-portage.com/dev-lang/squeak Arch: http://aur.archlinux.org/packages.php?ID=13021
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.
Great!
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 development efforts. Etoys is distributed as part of Sugar and depends on an up- to- date Squeak-VM package, so we do have allies in the Sugar maintainers. And everyone can help - as I wrote above, no deep VM knowledge is necessary to monitor bug trackers or keep contact with the maintainers.
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
- make etoys and squeak more compatible with etoys vm package.
- 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 -
On Thursday 16 April 2009 3:32:17 pm Bert Freudenberg wrote:
Squeakland should provide only Mac and Win installers, and work with the distros to carry an up-to-date Etoys package.
Expecting distros to package and distribute makes sense only for purely FOSS projects. Till the licensing questions around Squeak are cleared, distributors may not want to carry it in their repos.
What is the blocker for a proper deb repo on Squeakland?
Has anyone in the oversight board contacted medibuntu-maintainers (http://medibuntu.org/)?
Subbu
On 19.04.2009, at 16:24, K. K. Subramaniam wrote:
On Thursday 16 April 2009 3:32:17 pm Bert Freudenberg wrote:
Squeakland should provide only Mac and Win installers, and work with the distros to carry an up-to-date Etoys package.
Expecting distros to package and distribute makes sense only for purely FOSS projects. Till the licensing questions around Squeak are cleared, distributors may not want to carry it in their repos.
There is no licensing problem anymore for the VM, and neither for Etoys 4.0.
Even Debian did not object to the licensing anymore - it's in non-free because they do not like the idea of purely image-based development. Which is one of the reason why I'm only shooting for VM packages for now.
What is the blocker for a proper deb repo on Squeakland?
Has anyone in the oversight board contacted medibuntu-maintainers (http://medibuntu.org/)?
I don't think that's the board's job, and secondly medibuntu is for software with license issues. So no point as that does not apply to us anymore, not to the VM and not to Squeak 4.0 once it is released. I'm just saying we should not sit and wait until 4.0 is done, but make the distro contacts now, let the VM packages pave the way.
- Bert -
On Sunday 19 April 2009 8:11:17 pm Bert Freudenberg wrote:
I'm just saying we should not sit and wait until 4.0 is done, but make the distro contacts now, let the VM packages pave the way.
It is the image package which is installed. It would pull in VM as a dependency. Of course, the image could also come in as a file, but I would think that wouldn't be a complete case.
Am I missing something here? It has been a long day. I sure feel dense :-(
Subbu
On 19.04.2009, at 18:48, K. K. Subramaniam wrote:
On Sunday 19 April 2009 8:11:17 pm Bert Freudenberg wrote:
I'm just saying we should not sit and wait until 4.0 is done, but make the distro contacts now, let the VM packages pave the way.
It is the image package which is installed. It would pull in VM as a dependency. Of course, the image could also come in as a file, but I would think that wouldn't be a complete case.
Am I missing something here? It has been a long day. I sure feel dense :-(
My point is that Squeak developers all use their own images anyway. Most of them do only care about the VM to the point that they expect it to work. More importantly, they lack the skill to make the VM work. So the VM is the part of Squeak that is most needed to be pre-compiled and packaged. It's also the hardest part because of various dependencies on architecture, libraries etc.
I'm not saying images should not be packaged. I'm just advocating to start with the VM, for the various reasons I mentioned before (need, utility, difficulty, licensing). It for now would solve the hardest problem.
Note I'm not talking about packages available at squeak.org (which of course should package everything) but about the packages to become proper part of the various distros.
- Bert -
On Monday 20 April 2009 12:57:16 am Bert Freudenberg wrote:
My point is that Squeak developers all use their own images anyway. Most of them do only care about the VM to the point that they expect it to work. More importantly, they lack the skill to make the VM work. So the VM is the part of Squeak that is most needed to be pre-compiled and packaged. It's also the hardest part because of various dependencies on architecture, libraries etc.
What you say is true for developers but not sufficient for consumers. I would expect Squeak developers to be a small part of the universe of Squeak consumers (think of children and teachers). A image is what is needed, however small or however old. Eliot's suggestion to have a small bootstrap image is a good one. The image can help a Smalltalker navigate host file system and bring up a bigger image.
Subbu
On 20.04.2009, at 11:59, K. K. Subramaniam wrote:
On Monday 20 April 2009 12:57:16 am Bert Freudenberg wrote:
My point is that Squeak developers all use their own images anyway. Most of them do only care about the VM to the point that they expect it to work. More importantly, they lack the skill to make the VM work. So the VM is the part of Squeak that is most needed to be pre- compiled and packaged. It's also the hardest part because of various dependencies on architecture, libraries etc.
What you say is true for developers but not sufficient for consumers. I would expect Squeak developers to be a small part of the universe of Squeak consumers (think of children and teachers).
That's why Etoys is being packaged. For "consumers". With example projects, tutorials, online-help. That is already in the works, in particular as part of Sugar, which is an entry ticket for us. People want it in. But of course it does not depend on Sugar so works stand- alone, too. It *does* depend on a working and up-to-date Squeak-VM package.
A image is what is needed, however small or however old. Eliot's suggestion to have a small bootstrap image is a good one. The image can help a Smalltalker navigate host file system and bring up a bigger image.
This is a nice idea but also requires major additional work. The VM can be packaged right now, as is.
- Bert -
Bert Freudenberg wrote:
Even Debian did not object to the licensing anymore - it's in non-free because they do not like the idea of purely image-based development. Which is one of the reason why I'm only shooting for VM packages for now.
This approach does not make sense to me. What is the point of including Squeak VM to Debian without image(s) and sources? It would mean that half of the things is distributed in one way (through Debian repositories) and other things (images & sources) are distributed in other ways (users have to hunt for right kind of image and right kind of sources on the web). In my opinion, this approach is chaotic.
Including Squeak VM to Debian repositories could have been done anytime. I did try to do that because it alone makes little sense (my opinion).
On 19.04.2009, at 20:03, Matej Kosik wrote:
Bert Freudenberg wrote:
Even Debian did not object to the licensing anymore - it's in non- free because they do not like the idea of purely image-based development. Which is one of the reason why I'm only shooting for VM packages for now.
This approach does not make sense to me. What is the point of including Squeak VM to Debian without image(s) and sources? It would mean that half of the things is distributed in one way (through Debian repositories) and other things (images & sources) are distributed in other ways (users have to hunt for right kind of image and right kind of sources on the web). In my opinion, this approach is chaotic.
Including Squeak VM to Debian repositories could have been done anytime. I did try to do that because it alone makes little sense (my opinion).
In my opinion it does, and it solves the hardest problem first (see my reply to Subbu).
Going for all-or-nothing just prolongs the current undesirable situation unnecessarily. I'm proposing to go step by step. Of course, the people actually doing the work will decide on their own which path to take.
- Bert -
On Sun, Apr 19, 2009 at 12:38 PM, Bert Freudenberg bert@freudenbergs.dewrote:
On 19.04.2009, at 20:03, Matej Kosik wrote:
Bert Freudenberg wrote:
Even Debian did not object to the licensing anymore - it's in non-free because they do not like the idea of purely image-based development. Which is one of the reason why I'm only shooting for VM packages for now.
This approach does not make sense to me. What is the point of including Squeak VM to Debian without image(s) and sources? It would mean that half of the things is distributed in one way (through Debian repositories) and other things (images & sources) are distributed in other ways (users have to hunt for right kind of image and right kind of sources on the web). In my opinion, this approach is chaotic.
Including Squeak VM to Debian repositories could have been done anytime. I did try to do that because it alone makes little sense (my opinion).
In my opinion it does, and it solves the hardest problem first (see my reply to Subbu).
Going for all-or-nothing just prolongs the current undesirable situation unnecessarily. I'm proposing to go step by step. Of course, the people actually doing the work will decide on their own which path to take.
- Bert -
IMO the most sensible thing to include in a linux distro is a VM with a minimal headless scripting image that has the capability of loading packages to build whatever image one might want. This would allow one to write #!/bin/squeak scripts against some minimal base. But there is a lot of work here: - defining an elegant or pleasant to use file system interface instead of the rather broken one we have now (FileDirectory and FileStream have a horrible API, verbose, unintuitive, incomplete; file streams are slow (no buffering)) - defining a base scripting library (i.e. defining something minimal that is useful in a scripting context and well-designed enough to last) - providing python-quality documentation and breadth of functionality
But I'm saying this largely in ignorance of 3.10 and lack of experience with Rio which definitely looks to be a step in the right direction re verbosity.
2¢ Eliot
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eliot Miranda -
Jerome Peace -
K. K. Subramaniam -
Matej Kosik