Bug 861633
| Summary: | update squeak-vm to 4.10.x series | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthew Miller <mattdm> | ||||
| Component: | squeak-vm | Assignee: | Jaroslav Škarvada <jskarvad> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | dmcf, gavin, jskarvad, pavel.krivanek, samuel-rhbugs, smparrish, trevor.hemsley | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-11-27 04:43:09 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 856238 | ||||||
| Attachments: |
|
||||||
|
Description
Matthew Miller
2012-09-29 15:23:12 UTC
Also, the newer package includes plugins for Scratch support, making the Scratch packaging significantly simpler (bug #856238). Thanks! A number of possible issues I note in the latest upstream source tarball: 1. mp3 support is built in. 2. the FloatMathPlugin embeds a copy of the fdlibm library. (Not a licensing problem, just want to avoid the embedding) 3. JPEGReadWriter2Plugin likewise appears to embed source files from libjpeg. (ditto) Rudimentary testing shows that the new vm builds on Fedora 17 and the Squeak image runs under it. Also works with the Scratch image, and the Scratch plugin features work. And, note that the issues identified in comment #2 are also present in the existing Squeak 3.10.5 vm package, so my preference (from the point of view of getting Scratch packaged!) is to update the vm first and work on those issues second. Upstream informs me that there's an mp3-clean source tarball at http://squeakvm.org/unix/release/Squeak-4.10.2.2614-src-no-mp3.tar.gz or similar. Awesome. Hi Matthew, I have been attempting to become Squeak co-maintainer for some time, but no success so far (I will re-try to contact the maintainers again). Some time ago I also created custom updated SRPMs and gave them to Squeak community for testing. There are some problems, but it works at least: http://fedorapeople.org/~jskarvad/squeak/ I am also trying to package Pharo into Fedora as well. (In reply to comment #6) > Hi Matthew, I have been attempting to become Squeak co-maintainer for some > time, but no success so far (I will re-try to contact the maintainers again). Cool. Hopefully we can make this happen. I'm very interested in getting Scratch working but did not intend to go so deep into the Squeak rabbit hole here. > Some time ago I also created custom updated SRPMs and gave them to Squeak > community for testing. There are some problems, but it works at least: > http://fedorapeople.org/~jskarvad/squeak/ Can you give an idea of some of the problems? Updating that to Squeak-4.10.2.2614-src-no-mp3.tar.gz would be the first step, obviously. Debian has some patches which we might want to look into: http://patch-tracker.debian.org/package/squeak-vm/1:4.4.7.2357-1.1 and they have also done some work on breaking down the licensing situation: http://packages.debian.org/changelogs/pool/main/s/squeak-vm/squeak-vm_4.4.7.2357-1.1/squeak-vm.copyright (In reply to comment #7) > (In reply to comment #6) > > Hi Matthew, I have been attempting to become Squeak co-maintainer for some > > time, but no success so far (I will re-try to contact the maintainers again). > > Cool. Hopefully we can make this happen. I'm very interested in getting > Scratch working but did not intend to go so deep into the Squeak rabbit hole > here. > Sent another direct mail to Gavin and CCed Matthew. > > > Some time ago I also created custom updated SRPMs and gave them to Squeak > > community for testing. There are some problems, but it works at least: > > http://fedorapeople.org/~jskarvad/squeak/ > > Can you give an idea of some of the problems? > Pavel, could you comment on this as a tester? > Updating that to Squeak-4.10.2.2614-src-no-mp3.tar.gz would be the first > step, obviously. > > Debian has some patches which we might want to look into: > > http://patch-tracker.debian.org/package/squeak-vm/1:4.4.7.2357-1.1 > > and they have also done some work on breaking down the licensing situation: > > http://packages.debian.org/changelogs/pool/main/s/squeak-vm/squeak-vm_4.4.7. > 2357-1.1/squeak-vm.copyright > NP, I will look on it. I added some notes to the issue https://bugzilla.redhat.com/show_bug.cgi?id=861970 (In reply to comment #9) Pavel, one comment on that. The squeak-vm package will run images other than the one in squeak-image. That's why it makes sense to split them. They should be packaged, though, so that squeak-image depends on squeak-vm and not the other way around. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. *ping* Jaroslav -- any news? (In reply to comment #12) > *ping* Jaroslav -- any news? Some "intermediate" specs: http://fedorapeople.org/~jskarvad/squeak/squeak-vm-4.10.2.2614-1.fc19.src.rpm http://fedorapeople.org/~jskarvad/squeak/squeak-image-4.2.10966-1.fc19.src.rpm I need to resolve some problems - plugins, inisqueak and rework the images placing. I am currently @ LinuxCon so expect some delay :) Cool. I'll start updating the Scratch spec with that as a target. The VM a image work well when executed manually but mysqueak, squeak and squeak.sh scripts doesn't work: mysqueak: /usr/bin/mysqueak: line 5: exec: inisqueak: not found squeak: $ LC_ALL=en_US squeak Squeak4.2-10966.image which: no ckformat in (/usr/bin:/bin) cannot find VM to run image 'Squeak4.2-10966.image' with option '' $ LC_ALL=en_US squeak.sh Squeak4.2-10966.image which: no ckformat in (/usr/bin:/bin) cannot find VM to run image 'Squeak4.2-10966.image' with option '' (In reply to comment #15) > mysqueak: > /usr/bin/mysqueak: line 5: exec: inisqueak: not found > inisqueak seems to be missing from the upstream sources, but it is still noted in docs, thus probably it is not obsoleted, I need to check this more deep or maybe workaround it. > squeak: > $ LC_ALL=en_US squeak Squeak4.2-10966.image > which: no ckformat in (/usr/bin:/bin) > Maybe error in upstream installer, ckformat gets installed into sources, but it IMHO it should go into /usr/bin. I will probably workaround this. Also the following plugins are not build (currently I don't know why), but I will try to workaround it.: so.GStreamerPlugin so.KedamaPlugin so.KedamaPlugin2 Also a little update, new version of sqeuak-image SRPM: http://fedorapeople.org/~jskarvad/squeak/squeak-image-4.3-1.fc19.src.rpm What do you think about getting rid of the essentially-arbitrary "nonXOplugins", and instead putting the plugins into either individual subpackages or just putting them all into the main package? The current nonXOplugins subpackage is only about 50k, so it seems kind of superfluous. Also: the Scratch documentation notes a few specific requirements for building the plugins for that package. These should be moved to the squeak-vm package. Two are already there (pango-devel and glib2-devel) but without explicit versions; the others seem to be just missing. BuildRequires: cairo-devel > 1.8.6 BuildRequires: pango-devel > 1.20.5 BuildRequires: glib2-devel > 2.20.1 BuildRequires: libv4l-devel > 0.5.8 (uh, >=, not >, for each of those.) (In reply to comment #15) > $ LC_ALL=en_US squeak.sh Squeak4.2-10966.image > which: no ckformat in (/usr/bin:/bin) > cannot find VM to run image 'Squeak4.2-10966.image' with option '' This problem is caused by the hardcoded libdir on line 33 of /usr/bin/squeak -- it's fixed to "${prefix}/lib64/squeak". I kind of think we should replace all this wonky logic with fixed paths to the binaries we're actually installing. But failing that we could at least make the logic correct. :) It looks like /usr/bin/squeak.sh is simply an older version of the same script installed in /usr/bin/squeak. Our older package doesn't have a .sh version. The %files line should probably be changed from
%{_bindir}/*
to
%{_bindir}/squeak
so that future packages don't pick up errors like this.
> This problem is caused by the hardcoded libdir on line 33 of /usr/bin/squeak
> -- it's fixed to "${prefix}/lib64/squeak".
(Correction -- fixed to "${prefix}/lib/squeak". Sorry for the noise!)
In any case, once that's resolved, I think this is good to go into Rawhide -- it runs the Scratch image perfectly. Thanks for feedback, Matthew. I will push it into rawhide during this week. Update: http://fedorapeople.org/~jskarvad/squeak/squeak-vm-4.10.2.2614-1.fc18.x86_64.rpm http://fedorapeople.org/~jskarvad/squeak/squeak-image-4.3-1.fc18.noarch.rpm The inisqueak is missing, I will implement it. Then it should be usable. Latest SRPMs; http://fedorapeople.org/~jskarvad/squeak/squeak-vm-4.10.2.2614-1.fc18.src.rpm http://fedorapeople.org/~jskarvad/squeak/squeak-image-4.3-1.fc18.src.rpm Added several fixes, rewritten inisqueak, hopefully the last iteration :). In case of no bugreports I am going to push it to rawhide and f18 updates-testing tmrw (Friday 2012-11-23). Latest SRPMS: http://fedorapeople.org/~jskarvad/squeak/squeak-vm-4.10.2.2614-1.fc18.src.rpm http://fedorapeople.org/~jskarvad/squeak/squeak-image-4.3-1.fc18.src.rpm Latest RPMs: http://fedorapeople.org/~jskarvad/squeak/squeak-vm-4.10.2.2614-1.fc19.x86_64.rpm http://fedorapeople.org/~jskarvad/squeak/squeak-image-4.3-1.fc19.noarch.rpm Thank you very much, Jaroslav. I have some comments: - I think inisqueak should not run squeak at all. If you are in a directory where you create own image using inisqueak (without arguments), it creates the image well but then it starts the squeak.image from home directory. If it wants to open Squeak then it has to open the created image - the script "squeak" should (when no image was selected by an argument) firstly try to open squeak.image from the current working directory (it will fix the previous point too) - when there is a squeak.image in the working directory and there is no squeak.image in the home directory, the inisqueak -l does nothing and tries to open the image from the home directory. Very confusing - I think that the inisqueak should provide an option to modify generated image name. It is common to use own names for images and this way the user should rename the image manually (or save it with a different name where the original image is not deleted) - I'm not sure if home is the ideal place for squeak.image. I think that it should use a system variable for that ($SQUEAKHOME ???) with home directory as default - to list sqeuak.image together with image versions from the /usr/share/squeak is confusing. Maybe to rename the symlinks to latest(.image/.changes)? - I think you may remove the mysqueak script - to run "squeak" with an image as an argument doesn't work - I think that every source file should be in own package where image package will be dependent on it. The inisqueak script will then create a symlink to the sources file. This is the .st file content to print required source file for a specific image: FileStream stdout nextPutAll: SmalltalkImage current sourceFileVersionString. SmalltalkImage current snapshot: false andQuit: true. Maybe some comments will follow. (In reply to comment #28) Thanks for comments, refreshed version: http://fedorapeople.org/~jskarvad/squeak/squeak-vm-4.10.2.2614-1.fc18.src.rpm http://fedorapeople.org/~jskarvad/squeak/squeak-vm-4.10.2.2614-1.fc19.x86_64.rpm > - I think inisqueak should not run squeak at all. If you are in a directory > where you create own image using inisqueak (without arguments), it creates > the image well but then it starts the squeak.image from home directory. If > it wants to open Squeak then it has to open the created image > It was behaviour of the original script, inverted. I like the inverted version more. > - the script "squeak" should (when no image was selected by an argument) > firstly try to open squeak.image from the current working directory (it will > fix the previous point too) > Bug, fixed. > - when there is a squeak.image in the working directory and there is no > squeak.image in the home directory, the inisqueak -l does nothing and tries > to open the image from the home directory. Very confusing > Consequence of the previous bug, fixed. > - I think that the inisqueak should provide an option to modify generated > image name. It is common to use own names for images and this way the user > should rename the image manually (or save it with a different name where the > original image is not deleted) > Added -o option. > - I'm not sure if home is the ideal place for squeak.image. I think that it > should use a system variable for that ($SQUEAKHOME ???) with home directory > as default > Added this functionality to both inisqueak and squeak, used logic: SQUEAKHOME, fallback to working directory, fallback to $HOME > - to list sqeuak.image together with image versions from the > /usr/share/squeak is confusing. Maybe to rename the symlinks to > latest(.image/.changes)? > Fixed, symlinks are now skipped. > - I think you may remove the mysqueak script > Done. > - to run "squeak" with an image as an argument doesn't work > Consequence of other bug, fixed. > - I think that every source file should be in own package where image > package will be dependent on it. The inisqueak script will then create a > symlink to the sources file. > Multiple packages (like squeak-image-sources39, squeak-image-sources41) would quickly pollute the package list. In case that multiple packages needs to be installed simultaneously, it would probably require exception and I think it should behave like kernel packages. I think we cannot solve this correctly in the short-term, keeping as RFE. > This is the .st file content to print required source file for a specific > image: > > FileStream stdout nextPutAll: SmalltalkImage current > sourceFileVersionString. SmalltalkImage current snapshot: false andQuit: > true. > Thanks, maybe we will re-use this in the future, when "multiple sources in the same slot" will be implemented. Ok, thank you. I have some next quick comments: - inisqueak [rootdir] doesn't seem to work - if you combine parameters -o and -m for inisqueak, the home directory is used SQUEAKHOME=/home/krivanek/squeak inisqueak -o myimage -m Installing squeak.image.gz to /home/krivanek (In reply to comment #30) > - if you combine parameters -o and -m for inisqueak, the home directory is > used > > SQUEAKHOME=/home/krivanek/squeak inisqueak -o myimage -m > Installing squeak.image.gz to /home/krivanek I was not correct in the previous comment. The logic shown there was for 'squeak'. For inisqueak the behaviour is different and I think it is correct, it is: -m switch, SQUEAKHOME, current dir (In reply to comment #30) > Ok, thank you. I have some next quick comments: > - inisqueak [rootdir] doesn't seem to work I am not sure what was the intended behaviour of the original script, but for me the functionality seems to work correctly: $ ls -R /tmp/test /tmp/test: usr /tmp/test/usr: bin lib64 share /tmp/test/usr/bin: inisqueak squeak /tmp/test/usr/lib64: squeak /tmp/test/usr/lib64/squeak: 4.10.2-2614 /tmp/test/usr/lib64/squeak/4.10.2-2614: ckformat so.FileCopyPlugin so.SqueakFFIPrims so.vm-display-null so.vm-sound-OSS so.AioPlugin so.HostWindowPlugin so.UnicodePlugin so.vm-display-X11 so.vm-sound-pulse so.B3DAcceleratorPlugin so.MIDIPlugin so.UnixOSProcessPlugin so.vm-sound-ALSA so.WeDoPlugin so.CameraPlugin so.RomePlugin so.UUIDPlugin so.vm-sound-custom so.XDisplayControlPlugin so.ClipboardExtendedPlugin so.ScratchPlugin so.vm-display-custom so.vm-sound-NAS squeakvm so.DBusPlugin so.Squeak3D so.vm-display-fbdev so.vm-sound-null /tmp/test/usr/share: squeak /tmp/test/usr/share/squeak: Squeak4.3.changes.gz squeak.changes.gz squeak.sources.gz SqueakV4.sources.gz Squeak4.3.image.gz squeak.image.gz SqueakV41.sources.gz $ inisqueak No default image, looking for alternatives... I could not find an image to install. Please check your Squeak installation. $ inisqueak /tmp/test Installing squeak.image.gz to /home/yarda Unpacking '/tmp/test/usr/share/squeak/SqueakV41.sources.gz' to '/home/yarda/SqueakV41.sources' Unpacking '/tmp/test/usr/share/squeak/squeak.image.gz' to '/home/yarda/squeak.image' Unpacking '/tmp/test/usr/share/squeak/squeak.changes.gz' to '/home/yarda/squeak.changes' It doesn't use the root for $HOME / $SQUEAKHOME (I think it's OK). I am not sure if anybody have used this functionality before. I can eventually drop it. squeak-image-4.3-1.fc18,squeak-vm-4.10.2.2614-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/squeak-image-4.3-1.fc18,squeak-vm-4.10.2.2614-1.fc18 Package squeak-image-4.3-1.fc18, squeak-vm-4.10.2.2614-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing squeak-image-4.3-1.fc18 squeak-vm-4.10.2.2614-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18919/squeak-image-4.3-1.fc18,squeak-vm-4.10.2.2614-2.fc18 then log in and leave karma (feedback). squeak-image-4.3-1.fc18, squeak-vm-4.10.2.2614-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. Created attachment 799517 [details]
i686 build fails
One line patch to spec file to stop error finding SqueakFFIPrims on i[36]86 build
Build appears to work on CentOS 6 under mock with epel-6-i386 config (In reply to Trevor Hemsley from comment #36) > Created attachment 799517 [details] > i686 build fails > > One line patch to spec file to stop error finding SqueakFFIPrims on i[36]86 > build It works for me without the patch (i.e. there is so.SqueakFFIPrims) in rawhide i686. For which version you tried to build? Also in the future, please create new bugzilla reports for new defects. Also your patch doesn't apply, is it against squeak-vm-3.10.5? This was f17 which is EOL. (In reply to Jaroslav Škarvada from comment #38) > For which version you tried to build? Bug 1010329 |